Comments 34
Как будто курсовик прочитал.
Был такой костыль «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.
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.
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 человек, уязвимости просто гарантированы.
А в новом коде, который ещё ревьюит менее 100 человек, уязвимости просто гарантированы.
По вашей логике, и там и там уязвимости — просто гарантированы :) Как страшно жить…
Я лишь указал, что риски от добавления «security»-модулей могут перевесить преимущества
По вашей логике, могут и не перевесить. Вероятность-то, 50/50 :)
50 — это вы мне приписываете то, чего я не говорил.
Для ясности, моя позиция такова: намного надёжнее правильно сконфигурировать ядро, чем залатывать дыры малотестированным кодом. Хотя, если цель — попилить (на сертификации, поставках и т.п.), то тогда польза от вашей затеи есть. Только надо сразу чётко так и заявлять.
Для ясности, моя позиция такова: намного надёжнее правильно сконфигурировать ядро, чем залатывать дыры малотестированным кодом. Хотя, если цель — попилить (на сертификации, поставках и т.п.), то тогда польза от вашей затеи есть. Только надо сразу чётко так и заявлять.
en.sourceforge.jp/projects/akari/scm/svn/commits
Проект не сказать чтобы активно развивается, но как-то живёт.
Стоит наверное оперировать термином целевая система. Так вот, на целевой системе может действительно отсутствовать поддержка LSM.
Вы статью-то читали, или просто за одно осуждаете? Там же написано, что средства защиты бывают встроенными и наложенными. Сделать патч для ядра Linux — это как раз то, что называется встроенное средство. Как быть с системами, в которых это сделать невозможно?
Никто не может. Но по вашей логике мы дойдём до момента, когда любые попытки что-то сделать сведутся к абсудру, т.к. для чего что-то делать, если всё-равно нельзя ничего гарантировать? Но это не конструктивно, как вы понимаете :)
Проект не сказать чтобы активно развивается, но как-то живёт.
Если у вас клиенты пересобирают ядро с выключением CONFIG_SECURITY то тут уже ничего не поможет.
Стоит наверное оперировать термином целевая система. Так вот, на целевой системе может действительно отсутствовать поддержка LSM.
С другой стороны если нужно решать какую-то выходящую за рамки LSM задачу, достаточно наложить патч на ядро и дело в шляпе.
Вы статью-то читали, или просто за одно осуждаете? Там же написано, что средства защиты бывают встроенными и наложенными. Сделать патч для ядра Linux — это как раз то, что называется встроенное средство. Как быть с системами, в которых это сделать невозможно?
Гарантировать никто ничего не может.
Никто не может. Но по вашей логике мы дойдём до момента, когда любые попытки что-то сделать сведутся к абсудру, т.к. для чего что-то делать, если всё-равно нельзя ничего гарантировать? Но это не конструктивно, как вы понимаете :)
Хуки ничего не гарантируют. Вот вы пишете нулями какой-то сектор файла, а нижележащая реализация на физическом уровне запишет данные рядом, а старые не уничтожит. И что вы скажете клиентам, которые доверились вашей защите?
А мне так кажется (или только кажется?) что большинство комментирующих (или только оценивающих?) этот текст — просто дегенераты. ;-)
Ни о чём. LSM даже не упомянут, зато "патчить-патчить-патчить".
Так про LSM я всё сказал уже, что хотел:
https://habrahabr.ru/post/196372/
Ну с учётом актуальности на момент публикации.
По делу есть что сказать?
https://habrahabr.ru/post/196372/
Ну с учётом актуальности на момент публикации.
По делу есть что сказать?
Sign up to leave a comment.
Как сделать из ядра Linux Windows?