Открыть список
Как стать автором
Обновить

Комментарии 34

Как будто курсовик прочитал.
Мы старались, да :) Учтём и добавим к следующим материалам котиков ;)
Точно такие же мысли были.

Встраивание linux систем защиты позволяет встраивать системы защиты в linux информация защита система встраивание %)
Дайте угадаю, вы работаете SEO'шником?
Если честно нет, системный программист, в основном сетевая подсистема ядра Linux, дистростроение итд.
Был такой костыль «Linux Unified Kernel, Longene» в коем wine в ядро «запатчили»… вот только зачем?
ссылка
oldbay Не, ну вы буквально так не воспринимайте. Никто этого делать не собирается. Речь пойдёт о том, как встраиваться в ядро Linux и модифицировать его поведение в любых целях, в том числе для повышения защищённости системы. Но никто не мешает, например, на базе рассматриваемых методов делать такое: добавляем функцию «удалить в корзину». Чем не Windows? ;)
Все смешалось люди, кони…
Чем это лучше LSM? Его вроде бы специально для этого и придумали.
Это не лучше и не хуже LSM, у которого своя задача — обеспечивать возможность модульного расширения стандартной модели безопасности (DAC). Однако, с использованием LSM могут возникнут сложности, т.к. 1) LSM нельзя использовать вне ядра (интерфейсы смены модели де-факто не экспортируются) и 2) покрытие LSM-хуками хотя и обширно, но ограничено. Как, например, используя LSM реализовать очистку освобождаемой памяти или затирание остаточной информации на диске при удалении файлов?
1) И правильно делают. Защита вне ядра — не защита.
2) Покрытие LSM достаточно для контроля доступа субъекта к объекту, к очистке памяти это отношения не имеет. В LSM должен сидеть диспетчер доступа, его задача — форсирование политики безопасности. Диспетчер доступа вообще никаких манипуляций с ресурсами не производит и не должен этого делать ни в коем случае.

А очистка памяти в наших нормативных документах — это очень вольный перевод требований LSPP, где требованием является защита остаточной информации. То есть при повторном использовании ресурса в нём не должно быть остаточных данных и это правило выполняется ядром без особых проблем. Как конкретно TCB будет предотвращать доступ к повторно используемым ресурсам — другой вопрос. Попробуйте в Linux без прав рута и читерства с ptrace хоть как-то перекинуть данные без IPC.
1) И правильно делают. Защита вне ядра — не защита.

Вы, кажется, не уловили сути тезиса. Вне ядра, это не userspace. Это «в ядре», только отдельно :) Зацените проектик — AKARI. Он как раз вне ядра, но как бы «в ядре» :)))

2) Покрытие LSM достаточно для контроля доступа субъекта к объекту, к очистке памяти это отношения не имеет.

Именно. Поэтому я и отметил, что у LSM своя задача и в общем случае его использование не решит задачу контроля чего-то, контролировать что он не умеет. Если фантазировать дальше, то что вы будете делать, если опция CONFIG_SECURITY при сборке ядра оппаньки и выключена?..

Касательно же очистки памяти, вы говорите, что это
очень вольный перевод требований LSPP и… это правило выполняется ядром без особых проблем


А вот как быть с тем, что вы не можете гарантировать того, что ядро делает это?
Если фантазировать дальше, то что вы будете делать, если опция CONFIG_SECURITY при сборке ядра оппаньки и выключена?..

Если фантазировать дальше, ничто не поможет, если ядро собрано в single-user конфиге, без acl и групп доступа, где всё работает под рутом. Слишком много можно наделать дыр заранее, чинить решето заплатками неэффективно. Лучше сразу собирать правильно.
AKARI
Не вижу нигде кнопочки Download. Проект загнулся? И написано, что он основан на TOMOYO.
Если фантазировать дальше, то что вы будете делать, если опция CONFIG_SECURITY при сборке ядра оппаньки и выключена?..
Если у вас клиенты пересобирают ядро с выключением CONFIG_SECURITY то тут уже ничего не поможет. С другой стороны если нужно решать какую-то выходящую за рамки LSM задачу, достаточно наложить патч на ядро и дело в шляпе. Модули получается имеют только преимущество в том, что их проще отлаживать и распространять под проприетарной лицензией? Тем не менее, Grsecurity идёт именно как патч, да и много чего тоже оформляют как патчи, поскольку предполагают включение в апстрим.
А вот как быть с тем, что вы не можете гарантировать того, что ядро делает это?
Гарантировать никто ничего не может. Для этого нужно доказать математически, что всё, от микрокода процессора и контроллеров жесткого диска до ядра, работает именно так как декларировано. Я могу только зная заложенную в ядро идеологию говорить, что остаточную память постороннего пользователя вы не получите. Но сразу всплывает куча «НО»: система правильно настроена, в ней нет дырок и лазеек и т.п.
Самое печальное в этих модулях то, что они малопротестированы.
Вероятность, что в коде модуля есть уязвимость, намного выше, чем в коде чистого ядра, который засмотрен до дыр.
Для информации и размышления:

Security Vulnerabilities Published In 2014 (Execute Code)
CVE-2014-2523, CVE-2014-0049

Security Vulnerabilities Published In 2014 (Gain Privilege)
CVE-2014-4943, CVE-2014-4699, CVE-2014-3153, CVE-2014-2889, CVE-2014-2851, CVE-2014-1737, CVE-2014-1438, CVE-2014-0196, CVE-2014-0077, CVE-2014-0069, CVE-2014-0038

Здесь вероятность, думаю, нужно считать по типу встречи с динозавром — 50/50.
Я о чём и говорю — код засмотрен до дыр, а уязвимости со временем всё равно находят.
А в новом коде, который ещё ревьюит менее 100 человек, уязвимости просто гарантированы.
По вашей логике, и там и там уязвимости — просто гарантированы :) Как страшно жить…
Я лишь указал, что риски от добавления «security»-модулей могут перевесить преимущества
По вашей логике, могут и не перевесить. Вероятность-то, 50/50 :)
50 — это вы мне приписываете то, чего я не говорил.
Для ясности, моя позиция такова: намного надёжнее правильно сконфигурировать ядро, чем залатывать дыры малотестированным кодом. Хотя, если цель — попилить (на сертификации, поставках и т.п.), то тогда польза от вашей затеи есть. Только надо сразу чётко так и заявлять.
en.sourceforge.jp/projects/akari/scm/svn/commits
Проект не сказать чтобы активно развивается, но как-то живёт.

Если у вас клиенты пересобирают ядро с выключением CONFIG_SECURITY то тут уже ничего не поможет.


Стоит наверное оперировать термином целевая система. Так вот, на целевой системе может действительно отсутствовать поддержка LSM.

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


Вы статью-то читали, или просто за одно осуждаете? Там же написано, что средства защиты бывают встроенными и наложенными. Сделать патч для ядра Linux — это как раз то, что называется встроенное средство. Как быть с системами, в которых это сделать невозможно?

Гарантировать никто ничего не может.

Никто не может. Но по вашей логике мы дойдём до момента, когда любые попытки что-то сделать сведутся к абсудру, т.к. для чего что-то делать, если всё-равно нельзя ничего гарантировать? Но это не конструктивно, как вы понимаете :)
Хуки ничего не гарантируют. Вот вы пишете нулями какой-то сектор файла, а нижележащая реализация на физическом уровне запишет данные рядом, а старые не уничтожит. И что вы скажете клиентам, которые доверились вашей защите?
Вы правы в том, что сферические хуки в вакууме не гарантируют абсолютно ничего. Но мы понимаем, что там, в вакууме, нечего и защищать :) Средства защиты — это такие большие слоны, в которых конечно и хоботы есть и уши, и хвосты всякие :)
А мне так кажется (или только кажется?) что большинство комментирующих (или только оценивающих?) этот текст — просто дегенераты. ;-)
Зачем уж так скромно, "большинство"? Давайте скажем, что все.
Welcome to club.
Ни о чём. LSM даже не упомянут, зато "патчить-патчить-патчить".
Так про LSM я всё сказал уже, что хотел:
https://habrahabr.ru/post/196372/
Ну с учётом актуальности на момент публикации.
По делу есть что сказать?
А в статье есть что-то, что можно обсуждать? "Есть способы тем или иным способом добиться желаемого, более или менее целесообразные".
Ну дык, вам вводную статью дали. Вы потроллить решили. Есть конкретный вопрос — задавайте. А пустая болтовня к чему?..
Почему не средствами LSM?
Потому, что LSM ограничен теми местами в ядре, где стоят хуки.
Есть область контакта между userspace и ядром, не покрытая LSM? Я весь внимание.
Ну, к примеру, аудит системных вызовов, memory management. Что скажете?
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Информация

Дата основания
2008
Местоположение
Россия
Сайт
www.securitycode.ru
Численность
201–500 человек
Дата регистрации

Блог на Хабре