LINUX.ORG.RU

Блокирование доступа к Linux на промышленном уровне, Часть 2: Исполнение только подписанного кода


0

0

Это вторая статья из цикла, состоящего из двух частей, о защите ваших Linux-машин для оптимизации процессов поддержки и администрирования, в которой рассказано, как сконфигурировать ядро Linux для выполнения только подписанного двоичного кода.

>>> Подробности

★★★

Проверено: Shaman007 ()

На этот раз идея, описанная в статье, заслуживает внимания(в отличие от первой части).

Хорошо бы ещё создать дистрибутив, в котором все исполняемые _двоичные_(удаление интерпретаторов я по прежнему считаю бредом) будут подписаны. но это должен быть именно отдельный дисьрибутив, т.к. описанная в статье система сломается после первого же апгрейда.

gaa ★★
()

поздравляю огентов IBM со второй звездой!

geek ★★★
()

Интересно было бы увидеть расширение такой системы и на скрипты. Пока в голову приходит использование центральной подписаной базы хэшей скриптов и конфигов. Ну и проверка хэша (на уровне ядра) при открытии файла.

Новый дистрибутив (ИМХО) для этого не требуется - достаточно уметь перестраивать эту базу при выполнении апдейтов.

anonymous
()
Ответ на: комментарий от gaa

> т.к. описанная в статье система сломается после первого же апгрейда.

Если чуть-чуть подумать и сделать rmmod digsig upgrade sign executables modprobe digsig то не сломается.

anonymous
()

Прозреваю tivoization.

anonymous
()

обезьяний стиль изложения убивает.

"Don't call them 'Developers'. Monkeys."

З.Ы. nothing personal %)

gr_buza ★★★★
()

Респект автору.

Deleted
()
Ответ на: комментарий от anonymous

>> т.к. описанная в статье система сломается после первого же апгрейда.

> Если чуть-чуть подумать и сделать rmmod digsig upgrade sign executables modprobe digsig то не сломается.

А как же выдранный с корнем шелл и переписанные нах^W на C init-скрипты? Ведь всё обновлённое перезапишется файлами из дистрибутивных пакетов.

Кроме того, если бездумно переподписать все файлы в системе, то, подсунув свой файл куда-нибудь в /tmp, злоумышленник сможет после апгрейда запускать свой вредоносный код.

gaa ★★
()

Да здравствует DRM?

anonymous
()

ИМХО вдумчивое разбиения дисков и установка на разделы ключей ro и noexec решит проблему куда эффективней с точки зрения отношения затрачиваемые усилия/результат.

Sano
()

Из статьи не понял. Это дело распространяется и на конструкции вида
$ sh script.sh
$ python script.py
$ perl script.pl
или нет?

ilnurathome
()
Ответ на: комментарий от ilnurathome

> Из статьи не понял. Это дело распространяется и на конструкции вида $ sh script.sh $ python script.py $ perl script.pl или нет?

их ещё в прошлой части выковыряли

gaa ★★
()
Ответ на: комментарий от gaa

>Кроме того, если бездумно переподписать все файлы в системе, то, подсунув свой файл куда-нибудь в /tmp, злоумышленник сможет после апгрейда запускать свой вредоносный код.

--exclude /tmp --exclude /home

anonymous
()
Ответ на: комментарий от Sano

>ИМХО вдумчивое разбиения дисков и установка на разделы ключей ro и noexec решит проблему куда эффективней с точки зрения отношения затрачиваемые усилия/результат.

noexec - это вообще полная ДЫРА и элементарно обходится. Попробуй на досуге сделать "/lib/ld-2.6.1.so /your/noexec/partition/binaryfile". Очень удивишься...

anonymous
()
Ответ на: комментарий от anonymous

> noexec - это вообще полная ДЫРА и элементарно обходится. Попробуй на досуге сделать "/lib/ld-2.6.1.so /your/noexec/partition/binaryfile". Очень удивишься...

Когда в последний раз видел Linux, виндузятник?

$ ./uname
bash: ./uname: Permission denied
$ /lib/ld-linux.so.2 ./uname
./uname: error while loading shared libraries: ./uname: failed to map segment from shared object: Operation not permitted
$ /lib/ld-2.6.1.so ./uname
./uname: error while loading shared libraries: ./uname: failed to map segment from shared object: Operation not permitted

anonymous
()
Ответ на: комментарий от anonymous

PS

$ stat -c "%a" uname
755
$ mount|grep $PWD|grep -o "(.*)"
(rw,noexec,nosuid,nodev,loop=/dev/loop0,encryption=AES256)

anonymous
()
Ответ на: комментарий от anonymous

Это уже пофиксили года как два назад

roy ★★★★★
()
Ответ на: комментарий от Quasar

> Вот это и есть правильная реализация Trusted Computing

у tc не должно быть никакой реализации. и самого tc тоже

gaa ★★
()

> Блокирование доступа к Linux на промышленном уровне

Раздевать сотрудников до гола, проверяя наличие дистрибутивов линукса на всех возможных и невозможных носителях, зашитый ы биосы корпоративных компьютеров код, который сканит оперативную память и вырубает комп при встечи последовательность символов Linux, а так же прослушка всего. Вот это я понимаю, промышленный уровень...

AiFiLTr0 ★★★★★
()
Ответ на: комментарий от gaa

а в дверях не должно быть замков

anonymous
()
Ответ на: комментарий от iron

Да ладно вам. Очень пользительные статьи, такое начинание можно только приветствовать. Путсь средний уровень лора растет. Вдруг кто-то изменил лоровской традиции и перейдет по ссылки. Может что-то нове для себя найти.

Valmont ★★★
()

Чего-то не очень понимаю смысл всего этого геморроя. От рута (полученного обычным пользователем через какую-нибудь дырку) это же не защитит? Ну тогда какой смысл во всём этом? Обычного пользователя и стандартными средствами можно ограничить чтобы ресурсов много не сожрал...

Или это только чтобы люди на рабочих местах не игрались в игрушки? Так ИМХО это надо другими (не техническими) методами решать...

slav ★★
()
Ответ на: комментарий от alt0v14

>такая же тухлятина как и первая часть? )

ТруЪ ЛОР'овец может спать спокойно )))

P.S. Такая же как и в первой части

anonymous
()
Ответ на: комментарий от slav

>Чего-то не очень понимаю смысл всего этого геморроя. От рута (полученного обычным пользователем через какую-нибудь дырку) это же не защитит?

В комплекте с SELinux/AppArmor/... - защитит.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.