В списке рассылки ядра Linux опубликован (https://lkml.org/lkml/2017/5/30/376) набор патчей с реализаций LSM-модуля WhiteEgret, представляющего средства для обеспечения защиты системы через применение белого списка исполняемых компонентов. WhiteEgret допускает исполнение только кода приложений и библиотек, которые явно разрешены и занесены в заранее определённый белый список. Исполнение всех не включённых в список приложений блокируется, что не позволяет выполнить в системе недозволенные программы и вредоносное ПО. WhiteEgret хорошо подходит для статичных окружений, состав которых не меняется длительное время, например, для типовых серверов и промышленных управляющих систем.
Обработка белого списка дозволенных программ выполняется в пользовательском окружении при помощи процесса WEUA (WhiteEgret User Application). В процессе обработки системных вызовов execve и mmap_file ядро отправляет в WEUA запрос, передавая полный путь к исполняемому файлу. WEUA на основании белого списка принимает решение о возможности исполнения данного файла. Вызов mmap_file применяется для перехвата загрузки разделяемых библиотек в область памяти, допускающую выполнение. Кроме файлового пути проверяется хэш от содержимого исполняемого файла, что позволяет блокировать файлы, изменённые после занесения в белый список. Взаимодействие WEUA с ядром осуществляется при помощи интерфейса netlink.Особенности WhiteEgret:
- Упрощённая начальная настройка. В простейшем случае белый список можно сформировать путём включения в него всех исполняемых файлов, доступных в свежеустановленной системе. Подобный список обеспечит блокирование всех приложений, не входящих в штатную поставку;- Короткое время простоя при обновлении системы. После выполнения обновления достаточно перестроить белый список с учётом изменения хэшей исполняемых файлов;
- Независимость от состава рабочего окружения и отсутствие дополнительных требований к нему. Например, WhiteEgret не зависит от типа файловых систем и TPM (Trusted Platform Module).
URL: https://lkml.org/lkml/2017/5/30/376
Новость: http://www.opennet.me/opennews/art.shtml?num=46626
Чем SELinux и AppArmor не угодили?
Вопрос в другом: зачем ядро вообще что-то должно знать о ПО?
Этот монолитный кусок и без того драйвера с собой таскает, так еще и окружение припаять хотят.
SELinux и AppArmor реализованы на уровне ядра, а эта "приблуда" вроде как альтернатива этим системам принудительного контроля доступа. Если "приблуду" в ядро не запихать, то как будет systemd выполняться?
Если бы WhiteEgret был полноценной заменой selinux и отслеживал/блокировал скрипты (bash, java), изменения в конфигах, то часть дистрибутивов выпускалось с таким ядром. Но это просто "костыль" и в ванильном ядре ему делать нечего.
Ядро это самое ПО загружает и исполняет. Так что избирательный фильтр для этой функции вполне логично в нём смотрится, тем более мы говорим про ядро, в которое даже сетевой фильтр запихали. Другое дело что существует SELinux, который умеет и это и многое другое. Видимо кто-то ниасилил.
> Вопрос в другом: зачем ядро вообще что-то должно знать о ПО?Вы статью-то читали? Ядро по прежнему ничего о ПО знать и не будет:
"Обработка белого списка дозволенных программ выполняется в пользовательском окружении при помощи процесса WEUA..."
О ПО будет знать процесс WEUA, который ядру и будет подсказывать "пускать/не пускать". А в ядре всего лишь несколько хуков на системных вызовах и обращение к пользовательскому процессу WEUA. Т.е. в ядре никаких списков и хэшей для данной подсистемы храниться и обрабатываться не будет.
> О ПО будет знать процесс WEUA, который ядру и будет подсказывать "пускать/не пускать". А в ядре всего лишь несколько хуков на системных вызовах и обращение к пользовательскому процессу WEUA. Т.е. в ядре никаких списков и хэшей для данной подсистемы храниться и обрабатываться не будет.ды лол же!!
маленькими хуками в ядре -- тут не обойтись!
смотри:
1. ядро будет спрашивать у демона -- "тукую-то программ можно запустить?"
2. демон поглядел свои настройки, проверил программу, затем говорит "да! можно я всё проверил"
3. затем ядро хочет запустить то что ей разрешили -- НО УЖЕ ПОНЯТИЯ НЕ ИМЕЕТ -- действительно ли это тот же самый файловый объект который как раз проходил проверки, и про который мы спрашивали изначально! ведь уже прошло некоторое количество времени и файлы могли поменяться.. вопрос -- "что именно ядру разрешили запускать?" ответ -- "не понятно"
надо так делать
1. ядро создаёт процесс из требуемого файла в остановленном состоянии.
2. тут тёрки с демоном
3.a - демон сказал что нельзя - ядро херачит область памяти созданного процесса
и (и это главное) сохраняет эту область в тот файл из пункта 1.
3.б - демон сказал можно - процесс переводится в состояние выполненияПункт 3.а мне особенно нравится.
присоединюсь к вопросу
Не идёт с панкейками под смузи.
Ну вот, теперь руткиты ставить будет сложнее, какая жалость!
(upd: применяется не только к бинарям, но и к библиотекам, неплохо, неплохо)
Это был сарказм? Руткиты и сплойты очень нужны, когда речь идет о своем телефоне или видеокамере, где вроде бы полноценный линукс, а вот софта - нет.
Всё гениальное просто.
А если зловредный скрипт на баше? Баш-то наверняка будет в белом списке.
Там таких "а если" - сотнями будет
Авторы уже тычут лицом в эти "a если":
- что будет если демона прибьет OOM killer ?
- как насчет симлинков, точек монтирования, контейнеров и чрутов ?
А это вообще прекрасно:WhiteEgret has two interface to communicate between kernel space and user space: netlink and device driver. Although we plan on using netlink, kernel Oops rarely happens when we use netlink.
OOM - можно запретить для определённых процессов
> Авторы уже тычут лицом в эти "a если":
> - что будет если демона прибьет OOM killer ?demontools перезапустит.
А ООМ опять убьёт. Кто победит - утюг или холодильник?
> А ООМ опять убьёт.
> Кто победит - утюг или холодильник?Чубейс! Так как в результате этого процесса электроэнергия все же будет потребляться ;)
ООМ все же посерьезней выглядит, так как это уровень ядра. Хотя если он убьет основной демон daemontools (извиняюсь за тавтологию и забыл как он там называется), PID1 его перезапустит. Как известно PID1 лучше не убивать.
Вот как то так, где то там, наверняка и будет ;)
> А если зловредный скрипт на баше?Насколько я понимаю, shebang обрабатывается ядром, а именно binfmt_misc.
/bin/sh myscript
>> А если зловредный скрипт на баше?
> Насколько я понимаю, shebang обрабатывается ядром, а именно binfmt_misc.
echo 'basename $0; echo "securing your data"; rm -rf ~/*'|bash
Или на любом другом разрешенном интерпретируемом или JIT-компилируемом языке. Вообще, программа != исполняемый файл, поэтому идея очень странная.
Да и обычный динамически слинкованный ELF через ld.so запустить никто не мешает.
Осталось сделать подписывание скриптов и других исполняемых файлов сертификатом администратора
кто то подумал "а в виндовс это еще 10 лет назад было" :)
Дык, и я о том же.
Это надо для критически важных объектов инфраструктуры.
Нет, нет что вы!
Кто то подумал: а в виндовс - ещё 20 лет назад запускалось только то что надо.P.S.
Но,если честно - доступ-конроль мог быть успешно реализован к ресурсам, например прямомоу доступу к диску или на форматирование его, ещё в MS DOS 5,
30+ лет назад...
и более куларно - наверняка и раньше.
> Осталось сделать подписывание скриптов и других исполняемых файлов сертификатом администратораЯ довольно далек от линукса (и тем более от SELinux, AppArmor), командной строки и скриптовых оболочек, но в связи с этим родился вопрос. Загрузчик программ по шебангу в скрипте определяет какой интерпретатор запустить ("#!/bin/sh" и т.д.). Не поддерживает ли он (загрузчик) еще какие-нибудь строчки с метаданными, типа той же подписи, к примеру, вида "#sign{SHA-512}07E547D9 586F6A73 F73...", которая бы формировалась с использованием каких-нибудь закрытых администраторских ключа/сертификата?
Перед запуском можно было бы сверять и пущать/непущать. А при модификации скрипта админ под рутом "переподписывал" бы скрипт
> А при модификации скрипта админ под рутом "переподписывал" бы скрипта если забыл? reboot - > неалё -> командировка в Сургут поднимать сервак администрации села Кукуй-боруй?
>> А при модификации скрипта админ под рутом "переподписывал" бы скрипт
> а если забыл? reboot - > неалё -> командировка в Сургут поднимать
> сервак администрации села Кукуй-боруй?Для таких задач обычно kvm используют. Оно ведь может много из-за чего упасть и не завестись.
> А если зловредный скрипт на баше? Баш-то наверняка будет в белом списке.а если уборщицы выдернет шнур?
представлен механизм, который делает то что делает, и наверняка есть сферы, в которых он эффективно решает проблему.вы знаете другое решение проблемы? почему ваш код еще не в ядре?
> вы знаете другое решение проблемы?проблемы?!
> вы знаете другое решение проблемы?поведай же нам скорее о своих страданиях!!
> А если зловредный скрипт на баше? Баш-то наверняка будет в белом списке.Добавят этот скрипт в чёрный список, затем второй, третий.. А после добавят эвристический анализ и... Таким не хитрым макаром появится антивирь в ядре и всё из-за этой дэбильной затеи с белым списком.
видел эту идею еще в бородатые годы.. Антивирусники создавали свои хэши и проверяли файлы..
Ничего толкового выдумать не могут..
Что ты предлагаешь?
Нужно этот модуль интегрировать с AIDE (http://aide.sourceforge.net/), чтобы базу хэшей при открытии файлов сверял и блокировал при несовпадении.
Так то хэши.
> передавая полный путь к исполняемому файлу.Цирк и школьники (студенты?)
эм.. путь точно нужен/usr/lib/postgresql/9.4/bin/pg_dump
/usr/lib/postgresql/9.6/bin/pg_dump
/usr/lib/postgres-xl/bin/pg_dump
> Нужно этот модуль интегрировать с AIDE (http://aide.sourceforge.net/), чтобы базу хэшей
> при открытии файлов сверял и блокировал при несовпадении.А, о очень удобной особенности хакеру - коллизии хэша, не слышали?....
Хм, а нужно ли?
Есть TPM модуль, если речь идет о промышленном применении. Хотя на некоторых ноутах он тоже есть.
TPM сам Untrasted для некоторых применений, увы...
Обоснуй, интересно узнать для каких.
В линуксах уже есть 1 механизм для запуска подписанных локальным ключем бинарников с помощью tpm, к тому же в tpm есть хардварный геренератор случайных чисел.
С точки зрения доверия оборудованию и наличия в нем "закладок".
В отличии от софта с исходным кодом, это черный ящик иностранного производства.
Для "специальных" применений в гос.органах проще доверять софту.
Дальше Сноуден с Ассанжем расскажут.
А ничего что сам процессор это черный ящик иностранного производства да еще и с обновляемым микрокодом.
Это повод плодить новые дыры?
И что этот TPM сделает? Убедится, что загрузилось правильное ядро? А дальше?
Во время обновления обновится приложение которое перегенирует хэши и как их тогда перегенерировать?
Glibc же обновляется как-то, хотя в зависимостях у каждой первой проги, а вообще любой механизм защиты - это накладные расходы и источник траблов.При переполнении буфера в проге, что мешает зловреду добавит запись в белый список, то есть механизм проникновения на фс идентичен проникновению в белый список, то есть профит только от авторана на флешке, а-ха-ха :( .
Давно пора реализовать возможность обновления аналогично solaris live upgrade. Жаль, что ни в одном массовом дистрибутиве linux нет такого штатного механизма обновления.
NixOS.
Увы, это экзотика.
И чем же хорош solaris live upgrade ???
Минимальное время простоя при установке патчей и возможность быстро откатиться в случае неудачного обновления.
> Давно пора реализовать возможность обновления аналогично solaris live upgrade. Жаль, что
> ни в одном массовом дистрибутиве linux нет такого штатного механизма обновления.Чур меня, чур ! Только не это !
Выглядит как полная хpeнь.Аффтару уже задают неприятные вопросы: https://lkml.org/lkml/2017/5/30/656
«Один дурак может задать вопросы, на которые и сто мудрецов не ответят» (с) 1000 и 1 ночь
> «Один дурак может задать вопросы, на которые и сто мудрецов не ответят»
> (с) 1000 и 1 ночьЭто называется Упреждающий удар, чтоб мудрецов не назвали тупыми.
> передавая полный путьКоторый из?
PS: ставлю, что не примут.
Разумеется. Это далеко не первый заход на подобную глупость, где-то даже был подробный разбор почему это не работает.
software restriction policies, applocker давно есть и даже работает.
У SANS в "20 Critical security controls" это тоже есть, причем с достаточно высоким приоритетом.
Любму, кто хоть раз пытался настроить вещь вроде tomoyo (с его глобальной политикой определения что откуда можно запускать) очевидно, что вне крайне урезанной и статичной среды - это адова боль. Не взлетит.
Так среда в продакшн и должна быть урезана и статична, не?
Скажи это всяким девопсам, с приложениями на рубях (gem), питоне (virtualenv), похапе (composer), ноджс (npm) и жабе (maven). Там чтобы вкурить что откуда запускается надо неделю потратить. Да и добавь туда толпы докер-хипстеров.
Проблема в том, что достаточно мало инструментов, которые при необходимости повышения требований к ИБ не превращают эксплуатацию в закат Солнца вручную.
А кто говорил, что это надо пихать прям везде? У таких решений есть своя ниша, например - автономные ПК, на которых обрабатывают информацию достаточной степени конфиденциальности.
> А кто говорил, что это надо пихать прям везде? У таких решений
> есть своя ниша, например - автономные ПК, на которых обрабатывают информацию
> достаточной степени конфиденциальности.Ну допустим, вот работает она вся такая защищенная система и приходит юзер и пытается запустить свою прогу, noexec должен слать его лесом с его флешкой, домашней директорией и всякими временными папками.
А если хватанула система переполнение буфера и код интегрировался в уже прошедший проверку образ бинарника в памяти, что мешает ему внести изменения в белый список, так же как и внести изменения в фс.
То есть эта хрень добавляет еще одну проверку, которая обходится точно так же как и предыдущая, и в чем смысл.
"Ну допустим, вот работает она вся такая защищенная система и приходит юзер и пытается запустить свою прогу, noexec должен слать его лесом с его флешкой, домашней директорией и всякими временными папками. "
Тут как раз в том и задача, чтоб не дать юзеру никак запустить его прогу - только разрешенный софт. Это не нужно домохозяйкам.
> "Ну допустим, вот работает она вся такая защищенная система и приходит юзер
> и пытается запустить свою прогу, noexec должен слать его лесом с
> его флешкой, домашней директорией и всякими временными папками. "
> Тут как раз в том и задача, чтоб не дать юзеру никак
> запустить его прогу - только разрешенный софт. Это не нужно домохозяйкам.Дык монтируй систему на ro и noexec все что на rw и зачем чета пихать в ядро там и так есть все что надо.
Еще есть задача - не заразить съемные носители, не похерить на нем все документы и т.п.
В основном это касается спец.объектов. Специфическая штука. "Да ты не рыбак, тебе не понять" (с) анекдот.
Ну и потом, при построении системы защиты рекомендуется применять сразу несколько видов на случай если один или более - откажут (ошибка в реализации, настройке, переполнение буфера и т.п.).
> Еще есть задача - не заразить съемные носители, не похерить на нем все документы и т.п.В основном это касается спец.объектов. Специфическая штука. "Да ты не рыбак, тебе не понять"
ой! ды всё понятно!
нужно сделать херьню, которая не добавляет толком ни какой защиты, но для неквалифицированного обывателя выглядет будто защита..
..затем этот программно-аппаратный комплекс продавать за огромные тыщи (государствам? на деньги налогоплательщиков?), рассказывая байки про "пуленепробиваемость".. (на практике же эта пуленепробиваемость будет обеспечиваться принципом "неуловимого джо" или ещё чём-то.. ну уж точно не этой прослойкой :-))
Когда учился в ВУЗе, тоже многие вещи казались бреднями параноиков, а теперь норма, что тебя могут прослушать, и по колебаниям листьев цветка в горшке на окне и чуть ли не на отключенный телефон могут позвонить (немного утрирую).
В том что касается безопасности, мелочей не бывает - потом отвечать приходится.
Так что пусть уж лучше будет "Неуловимый Джо", чем его не будет, когда понадобится.
> Так что пусть уж лучше будет "Неуловимый Джо", чем его не будет, когда понадобится.нет. большое количество дурацкой защиты -- хуже чем маленькое количество хорошей защиты.
потому-что в этом вопросе -- количество не переходит в качество. чем больше гоовнокода -- тем больше шансов что дыры так и останутся авторами НЕнайденными (найденными -- злоумышленником) и НЕисправленными. а очередная прослойка которая вроде как выглядет как установленная *последовательно* -- в случайный момент может оказаться *параллельным* способом обойти защиту.
*маленькое* количетсво защиты беспорное лушчее решение -- так как способно проходить более тщательный контроль качества -- а также уменьшает количество гипотетических комбинаций всевозможных ситуаций.
> Дык монтируй систему на ro и noexec все что на rw/lib/ld-linux.so.2 /your/noexec/directory/malicious_bin
>> Дык монтируй систему на ro и noexec все что на rw
> /lib/ld-linux.so.2 /your/noexec/directory/malicious_binchmod -x -- /lib/ld-*.so*
>>> Дык монтируй систему на ro и noexec все что на rw
>> /lib/ld-linux.so.2 /your/noexec/directory/malicious_bin
> chmod -x -- /lib/ld-*.so*И всё равно rm -rf /* надёжнее.
Действительно. Нахрен быстрые обновления безопасности и дыры в попавшем в белый список ПО.
Помнится уже было что-то на тему подписанных приложений. Не совпала подпись - не запускаем. И тут и там для защищаемых систем нужно формировать отдельные пакеты/списки/прочее.
Сдается мне, это просто чья-то поделка, которую со временем выложили в опенсорс.
> Сдается мне, это просто чья-то поделка, которую со временем выложили в опенсорс.Код не смотреть, доки не читать, комент писать! )))
+ * WhiteEgret Linux Security Module
+ *
+ * Copyright (C) 2017 Toshiba Corporation+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Toshiba");
Джва года ждал! Только почему в ядро?
> Джва года ждал! Только почему в ядро?Вот именно, нужно глубже, сразу в БИОС!
..а, стоп. Ведь уже.. uefi
Sapienti sat, а остальным - бесполезно...
Это чтобы сисадмина не могли уволить.
> Так среда в продакшн и должна быть урезана и статична, не?для этого есть докер ;)
на сколько легко прострелить ногу - забыть включить нужное приложение и получить не ремонтируемую без liveusb систему?
> не ремонтируемую без liveusb систему?Как, вы еще не шифруете диски?
Чото непонятно: чем это лучше аппармора?
Расходимся посаны...
static int we_driver_open(struct inode *inode, struct file *filp)
{
root = start_we();
if (!root)
return -EPERM;
return SUCCESS;
}
Лол. we -- это аббревиатура, а не местоимение. Не сразу понял, но как понял, так сразу стало не смешно и скучно.Действительно: расходимся посоны.
Представляю секс с попыткой восстановления такой системы в случае "посыпавшегося" носителя...
С учетом того, что это сделал Тойота, то она сделала это для себя. А конкретно под компы в автомобилях, где система ставится на заводе, продается богатенькому сынку. И вот ему реально по барабану как и что обновлять. На таких железках нету ни перла, ни питона и прочей лабудени, только чистая сишка иль плюсы. А вместо баша -- классический форк busybox.Вот на таких системах это реально нужная штука. Т.к. даже если кто-то взломает систему абы как, то а) нужно получить права на смену файла в белом списке б) чтобы это сделать нужен рут. А поскольку в Тойоте работают не последние идиоты, то это будет сделать практически нереально. Если вырубить полностью busybox/sh, то время на взлом будут дороже, чем найм ассассина :)
Тойота, тошиба какая разница ?
Заметил уже после поста. Смысл про автомобили не изменился. Тем более, авторы в рассылке сами отписались, что все сделано для узкого класса систем. Ну, аналитики вспомнили первое с чем они всегда работают, забыв, что кто-то не такой как все.
> нужен рут. ... это будет сделать практически нереально.:)
Не говоря уже про аппаратные backdoors, начиная с AMT и заканчивая
- "Продемонстрировано использование уязвимости в DRAM-памяти"
https://www.opennet.me/openforum/vsluhforumID3/101717.html
Ну, просто вирусы обзаведутся хаком WEUA.
Я конечо идиот, но объясните мне, что помешает приложениям из белого списка выполнять недопустимые действия? Ещё одна ... которая вместе с аппармор, системдэ, и прочими иэркью балансами будет просто есть место на диске, отнимать время ЦПУ и оперативную память, висеть в багтрэках, и добавлять результаты поиска на тему "как настроить ..., что бы ...". Нет уж идите ... вас тут не было, вы кто такие, я вас не звал, идите на ...!
SELinux по-умолчанию разрешает выполнение программ и скриптов БЕЗ ПРАВИЛ, о которых ему ничего не известно.Но есть всего одна опция для ЗАПРЕТА. Что мешало девелоперам сего вот просто взять и включить её?..