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

kill ibm_dw

а статья ничего даже.

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

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

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

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

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

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

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

Прозреваю tivoization.

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

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

З.Ы. nothing personal %)

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

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

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

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

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

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

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

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

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

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

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

--exclude /tmp --exclude /home

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

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

> 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

PS

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

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

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

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

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

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

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

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

IBM_dW забанить ! Или ЛОР на лапу от IBM получает ?

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

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

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

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

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

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

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

Но статья про загрузку с зашифрованных разделов "paranoid mode" круче была.

по ссылке не ходил, но осуждаю.

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

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