The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

AppArmor и Yama будут включены в Linux-ядро 2.6.36

31.07.2010 08:35

Джеймс Моррис (James Morris), куратор разработки Linux по вопросам безопасности, сообщил, что патчи, обеспечивающие поддержку технологий AppArmor и Yama, поставлены в очередь на включение в основную ветку разработки ядра Linux, и должны войти в выпуск 2.6.36.

AppArmor

Данная технология является одной из реализаций мандатного контроля доступа для Linux. Изначально она была разработана компанией Immunix. Впоследствии эта компания была куплена Novell'ом, AppArmor был открыт под лицензией GPL и включен в ядро openSUSE. Кроме того, поддержка AppArmor была включена в дистрибутивы Mandriva и Ubuntu. Однако, некоторое время спустя, основатель и главный разработчик AppArmor Криспин Коуэн перешел на работу в Microsoft, а Novell объявила о начале полноценной поддержки в своих продуктах конкурирующей технологии SELinux, начиная с openSUSE 11.1 (подробнее об этих событиях). Впоследствии разработка AppArmor была возобновлена Джоном Йохансеном, сотрудником Canonical.

AppArmor позволяет контролировать полномочия процессов, определяя списки файлов с соответствующими правами (на чтение, запись, отображение в память и запуск, установку блокировки на файл и т.п.) для каждого приложения. Также AppArmor позволяет на самом общем уровне контролировать доступ к сети (например, запретить использование ICMP) и управлять POSIX capabilities.

Распознавание приложений и, соответственно, определение их полномочий, производится по имени исполняемого файла. Именно этот момент очень часто выступает ключевым в критике AppArmor. Действительно, подменив имя исполняемого файла, злоумышленник может вывести приложение из-под контроля AppArmor. Самый простой пример — создание жесткой ссылки. Более сложный вариант — выполнение mount --bind или pivot_root. Разумеется, последние два подхода должны блокироваться классической (дискреционной) системой контроля доступа, однако мандатный контроль доступа обычно вступает в игру после того, как дискреционный контроль удалось обойти (например, злоумышленник обнаружил уязвимость в suid-программе).

Конкурирующие решения для обеспечения мандатного доступа, SELinux (включен в ядро начиная с 2.6.0) и SMACK (включен в ядро начиная с 2.6.25), не подвержены подобным уязвимостям, так как используют метки безопасности, хранящиеся непосредственно в inode файла. Недостатком такого подхода является необходимость поддержки меток безопасности на уровне файловой системы. Однако в настоящее время такие метки поддерживаются большинством популярных файловых систем Linux, за исключением ReiserFS (версия 3.6 поддерживает Security Labels) и Reiser4. С другой стороны, не стоит забывать, что такие важные для промышленных задач возможности, как многоуровневая защита (MLS) и контроль доступа на основе ролей (RBAC) реализованы пока только в SELinux.

Также стоит отметить другого ключевого конкурента AppArmor — проект TOMOYO, принятый в ядро начиная с 2.6.30. Как и AppArmor, TOMOYO использует для различения программ пути к исполняемым файлам, однако его разработчики уделили гораздо больше внимания возможностям обхода такой защиты. В частности, TOMOYO, в отличие от AppArmor, позволяет контролировать права на операции mount --bind и pivot_root. Кроме того, в TOMOYO существует очень полезная возможность — контроль контекста вызова, например, для файла /bin/bash, запущенного файлом /usr/sbin/sshd, можно задать совсем другие права, нежели для того же файла /bin/bash, но запущенного файлом /bin/login.

Yama

Это простой модуль, разработанный для Ubuntu компанией Canonical и использующий возможности Linux Security Model для блокировки некоторых типов атак, в частности,

  • Атак через подстановку символьной ссылки в общедоступном каталоге, например, /tmp. Многие приложения хранят свои временные файлы и символьные ссылки в каталогах, доступных на запись всем пользователям. В некоторых случаях злоумышленник может подставить свою символьную ссылку, обманом заставив приложение открыть совсем не тот файл. Yama позволяет заблокировать такую атаку, разрешив следование по символьным ссылкам в подобных каталогах только в том случае, если UID владельца символьной ссылки совпадает с UID процесса, пытающегося следовать по ссылке.
  • Атак с использованием жестких ссылок. Разумеется, если некоторый файл недоступен на чтение либо запись для какого-либо пользователя, жесткая ссылка на данный файл будет иметь те же права и поэтому также будет недоступна этому пользователю. Однако, используя жесткие ссылки, злоумышленник может «подсунуть» такой файл приложению, которое имеет права на доступ к нему. Yama позволяет заблокировать эту атаку, запретив создание жестких ссылок пользователям, не имеющим прав на доступ к исходным файлам.
  • Атак с использованием отладочного вызова ptrace. Без использования соответствующей защиты Yama, любой процесс с привилегией CAP_SYS_PTRACE может обращаться к памяти всех процессов с тем же UID'ом. При использовании Yama, можно ограничить область доступа только памятью, принадлежащей потомкам такого процесса.


  1. Главная ссылка к новости (http://lwn.net/Articles/398191...)
  2. Сравнение систем мандатного контроля доступа в Linux
  3. Обзор подсистем безопасности Ubuntu
  4. OpenNews: Система безопасности AppArmor доступна для Ubuntu 7.04
  5. OpenNews: Оценка шансов AppArmor войти в состав Linux ядра
  6. OpenNews: Компания Canonical повторила попытку интегрировать AppArmor в основное Linux ядро
Автор новости: Sergey Ptashnick
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/27488-linux
Ключевые слова: linux, kernel, apparmor, yama, security, lsm
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (51) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.2, KERNEL_PANIC (ok), 10:24, 31/07/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Я то думал, что на АррАrmor уже давно все забили и оно в анабиозе гдето лежит. Как оказывается, нет, его еще в ядро пхнут. Как будто других получше технологий не хватает...
     
     
  • 2.3, goof.gooffy (ok), 12:33, 31/07/2010 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Тебе оно мешает? Не хочешь - не используй.
    Вреда не принесет, а польза будет явно
     
     
  • 3.4, dimqua (ok), 12:57, 31/07/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Ну из описания, например, не понятно какие у неё плюсы по сравнению с SELinux.
     
     
  • 4.5, Аноним (-), 13:15, 31/07/2010 [^] [^^] [^^^] [ответить]  
  • +7 +/
    а плюсов нет
    До селинукса этим велосипедам далеко
     
     
  • 5.14, User294 (ok), 22:17, 31/07/2010 [^] [^^] [^^^] [ответить]  
  • –8 +/
    > До селинукса этим велосипедам далеко

    Только в настройке геморроен и если кто считает что селинуху нельзя поднасрать - он читает новости про эксплойты с повышением прав в линухе (было тут в новостях). Почему-то сплойты первым делом SELinux выпилиывают, чтоб под ногами не мешался :). А так геморная штука, как только что-то окромя стандартных операций надо - сливай вода, туши фонарь. ИМХО можно достичь сравнимой секурити куда менее геморными методами, скажем путем простой распиловки на отдельные изолированные контейнеры. И эффективно, и просто.

     
     
  • 6.26, аноним (?), 00:18, 01/08/2010 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Видимо, вы просто плохо понимаете, как работает Linux.

    >если кто считает что селинуху нельзя поднасрать - он читает новости про эксплойты с повышением прав в линухе (было тут в новостях). Почему-то сплойты первым делом SELinux выпилиывают, чтоб под ногами не мешался
    >ИМХО можно достичь сравнимой секурити куда менее геморными методами, скажем путем простой распиловки на отдельные изолированные контейнеры.

    Контейнеры дают ровно такую же защиту, как и LSM-based MAC (в частности, selinux). Потому что если имеется критическая уязвимость _в самом ядре_, любые средства, работающие на уровне ядра и ниже, _абсолютно бессильны_. В этой ситуации защитить могут только над-ядерные методы - гипервизор (xen) или физическое разделение по серверам.

    >А так геморная штука, как только что-то окромя стандартных операций надо - сливай вода, туши фонарь

    Вы уж определитесь, либо оно вам надо, и тогда изучайте и не пишите глупостей, либо оно вам совершенно не нужно, и тогда забудьте о такой вещи, как мандатный контроль доступа.

     
     
  • 7.29, User294 (ok), 11:27, 01/08/2010 [^] [^^] [^^^] [ответить]  
  • –7 +/
    Не линукс а искусственные довески к нему в виде всяких SELinix-ов и прочие манда... большой текст свёрнут, показать
     
     
  • 8.35, аноним (?), 14:27, 01/08/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Контейнеры - ровно так же Срубаются в два счета Да-да, для использования уязви... текст свёрнут, показать
     
     
  • 9.48, User294 (ok), 02:16, 04/08/2010 [^] [^^] [^^^] [ответить]  
  • –1 +/
    А пруф Например, образец сплойта который вышибет хоть тот же опенвз Примеры сп... текст свёрнут, показать
     
  • 6.27, аноним (?), 00:20, 01/08/2010 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Резюмируя: контейнеры дают ровно такую же степень защиты, как и LSM, при этом проще в настройке (особенно если автоматизировать развертывание окружений), но жрут гораздо больше ресурсов и не так гибки в настройке.
     
     
  • 7.30, User294 (ok), 11:43, 01/08/2010 [^] [^^] [^^^] [ответить]  
  • –5 +/
    >но жрут гораздо больше ресурсов

    Да не настолько уж и больше. Зависит от конкретики, конечно. Кстати думается что kernel same pages merging может сие пролечить.

    >и не так гибки в настройке.

    Напротив, гораздо гибче. В каждом может жить своя система. С своими настройками, своими квотами пожирания ресурсов хоста и прочая.


     
     
  • 8.36, аноним (?), 14:29, 01/08/2010 [^] [^^] [^^^] [ответить]  
  • +/
    А про то, что в каждом контейнере пашут всякие вспомогательные службы типа sshd,... текст свёрнут, показать
     
     
  • 9.49, User294 (ok), 02:48, 04/08/2010 [^] [^^] [^^^] [ответить]  
  • –1 +/
    При некоторой организации процесса sshd можно и совсем не запускать можно напри... текст свёрнут, показать
     
  • 4.6, Аноним (-), 13:16, 31/07/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >Ну из описания, например, не понятно какие у неё плюсы по сравнению
    >с SELinux.

    Главный плюс AppArmor в том, что с ней можно разобраться за 5 минут, там очень простая, очевидная и логичная система настроек. SELinux шею можно свернуть разбираясь с нюансах.
    Сравните политики для SELinux и правила AppArmor, это небо и земля.

     
     
  • 5.13, Аноним (-), 18:26, 31/07/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Ну дык будь последовательным и:
    сравни _возможности_ SELinux и AppArmor, это небо и земля.(С) :)

    Первым можно таки реально защитить систему. Вторым - можно сделать вид что защитил ....

     
     
  • 6.15, User294 (ok), 22:20, 31/07/2010 [^] [^^] [^^^] [ответить]  
  • –6 +/
    >Первым можно таки реально защитить систему. Вторым - можно сделать вид что защитил ....

    Первым можно задолбаться защищать систему и его могут сломать (смотрим как работают сплойты юзавшие повышение прав в линухе и делаем выводы). Второй внушает еще меньше доверия. Как по мне - лично я при параное пилю все на отдельные контейнеры просто. Изоляция - отличная. И долбаться с селинухом не надо.

     
     
  • 7.23, аноним (?), 23:48, 31/07/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >Первым можно задолбаться защищать систему

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

    >его могут сломать (смотрим как работают сплойты юзавшие повышение прав в линухе и делаем выводы)

    Если уязвимость в ядре, могут сломать любой механизм изоляции, включая LSM-based MAC или те же контейнеры.

    >Как по мне - лично я при параное пилю все на отдельные контейнеры просто

    Очень продуктивно. По сравнению с selinux - сильно экономит место на диске, память и нагрзку на проц. Зато уровень защиты тот же.

     
     
  • 8.31, User294 (ok), 12:04, 01/08/2010 [^] [^^] [^^^] [ответить]  
  • –6 +/
    В природе есть два мнения - ваше и неправильное Сильно зависит от контейнеро... большой текст свёрнут, показать
     
     
  • 9.34, аноним (?), 14:18, 01/08/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Ну вы сразу бы и говорили, что вы скрипт кидди, и ничего не понимаете в работе с... текст свёрнут, показать
     
     
  • 10.50, User294 (ok), 03:42, 04/08/2010 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Да, если дело дошло до хоста и его ядра А удастся ли спровоцировать проблему из... текст свёрнут, показать
     
  • 6.16, Аноним (-), 22:26, 31/07/2010 [^] [^^] [^^^] [ответить]  
  • –3 +/
    >Ну дык будь последовательным и:
    >сравни _возможности_ SELinux и AppArmor, это небо и земля.(С) :)
    >
    >Первым можно таки реально защитить систему. Вторым - можно сделать вид что
    >защитил ....

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

     
     
  • 7.24, аноним (?), 23:50, 31/07/2010 [^] [^^] [^^^] [ответить]  
  • +2 +/
    >AppArmor не ставит перед собой глобальных целей, он просто позволяет не дать
    >запускаемому приложению больше, чем нужно, отсекая все лишнее. Этого в подавляющем
    >большинстве случаев более чем достаточно.

    Так должна работать нормальная система MAC, например, selinux в targeted-режиме.
    apparmor, с учетом его тотальной уязвимости, лишь создает видимость защиты.

     
  • 6.28, StrangeAttractor (ok), 02:59, 01/08/2010 [^] [^^] [^^^] [ответить]  
  • –3 +/
    > сравни _возможности_ SELinux и AppArmor, это небо и земля.(С) :)
    > Первым можно таки реально защитить систему. Вторым - можно сделать вид что защитил ....

    Рискну высказать своё некомпетентное (в уме не е-у ни байта ни про SELinux ни про AppArmor) мнение. В руках некого админа надёжна только та система, в т.ч. система защиты, которую он полностью понимает. И чем проще система, тем она практически надёжней. По этому AppArmor вроде как предпочтительнее. А если не понимаешь ни то ни то, лучше вообще выпилит их нафиг и настраивать секюрити по-старинке, что я и делаю. А плодить дополнительные сущьности, пытаться защищаться надстройками не будучи уверенным (а если был бы - так они и не нужны) в том, что внутри - дело сомнительное.

     
  • 4.9, аноним (?), 15:41, 31/07/2010 [^] [^^] [^^^] [ответить]  
  • +7 +/
    >Ну из описания, например, не понятно какие у неё плюсы по сравнению с SELinux.

    Не надо сравнивать кислое с длинным.
    selinux - для защиты промышленных серверов, обслуживаемых квалифированными админами. Поэтому пофиг на простоту, там главное гибкость и мощь.
    apparmor, smack, tomoyo - для защиты десктопа юзера Васи или шлюза маленького офиса, поднятого стунентом за полставки. Вот тут гибкость уже на последнем месте, а на первом - простота.

    Другое дело, что непонятно, какие плюсы есть у apparmor по сравнению с тем же tomoyo.
    tomoyo умеет все то же самое плюс еще многое (например, "контроль контекста вызова" - офигенная фича), и в ядре уже относительно давно, и настройки у него такие же простые.
    Видимо, убунтовцы просто поленились переписывать конфиги, решив, что легче будет просто протолкнуть apparmor в ядро. Что ж, уних это удалось, рад за них. Но вот за ядро обидно.

     
     
  • 5.18, User294 (ok), 22:36, 31/07/2010 [^] [^^] [^^^] [ответить]  
  • –5 +/
    >Поэтому пофиг на простоту, там главное гибкость и мощь.

    Не согласен. Если система сложная, админу труднее умещать ее в своей голове. Растет риск облажаться. Как по мне - проще сервак на контейнеры нарезать чем изгаляться с селинухом. Изоляция на уровне и возни меньше.

     
     
  • 6.21, slepnoga (??), 22:51, 31/07/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >>Поэтому пофиг на простоту, там главное гибкость и мощь.
    >
    >Не согласен. Если система сложная, админу труднее умещать ее в своей голове.
    >Растет риск облажаться. Как по мне - проще сервак на контейнеры
    >нарезать чем изгаляться с селинухом. Изоляция на уровне и возни меньше.
    >

    Админу? тык кто его пустит то политики вертеть ? Не его это дело, а таки спеца по  ИТ безопасности.
    Дело админа - применить или протестить.
    Если это все по другому сделано - то и селинух там нафик не нужен

     
     
  • 7.32, User294 (ok), 12:14, 01/08/2010 [^] [^^] [^^^] [ответить]  
  • –2 +/
    >Админу? тык кто его пустит то политики вертеть ? Не его это дело, а таки спеца по
    >ИТ безопасности.

    Угу, для управления парой серверов ща отрастим бюрократическую машину по принципу "один солдат и куча начальников" :-). Не, в здоровом энтерпрайзе это может и реально, однако я видел весьма серьезные энтерпрайзы которых давила жаба на такую схему. Самое странное что глобальных поимений почему-то не наблюдалось.

    >Дело админа - применить или протестить.

    Похоже на обоснование нужности выделенного безопасника. А энтерпрайзы с вами согласны? В лично моем понимании - хорошо когда есть кто-то прорабатывающий стратегии защиты, однако по моим наблюдениям энтерпрайзы часто не желают платить такому специалисту адекватную зарплату. А зарплата уровня стандартного эникейца для такого спеца - гхм, извините не прикольно как-то.

     
  • 6.25, аноним (?), 23:55, 31/07/2010 [^] [^^] [^^^] [ответить]  
  • +2 +/
    >Не согласен. Если система сложная, админу труднее умещать ее в своей голове.
    >Растет риск облажаться.

    Вы, видимо, просто никогда не работали с selinux.
    Да, для изучения базовых навыков работы с этой системой нужно затратить некоторые усилия, пошевелить мозгом (для этого, кстати, необходим сам мозг). Но, поняв внутреннюю логику системы и усвоив базовые операции, человек уже никогда там не заблудится.
    Это как арифметика.

    >Как по мне - проще сервак на контейнеры нарезать чем изгаляться с селинухом. Изоляция на уровне и возни меньше.

    Вам - меньше, серваку - больше.

     
     
  • 7.33, User294 (ok), 12:22, 01/08/2010 [^] [^^] [^^^] [ответить]  
  • –4 +/
    Как вам сказать Я посмотрел на его политики, сломал моск и решил что могу не ху... большой текст свёрнут, показать
     
     
  • 8.37, аноним (?), 14:33, 01/08/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Позвольте узнать, ваше знакомство с арифметикой закончилось так же Ага, а еще я... текст свёрнут, показать
     
     
  • 9.51, User294 (ok), 13:26, 09/08/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Нет, почему же, я знаю и высшую математику Только, простите, я успешно забыл на... текст свёрнут, показать
     
  • 3.7, MidNighter (?), 13:16, 31/07/2010 [^] [^^] [^^^] [ответить]  
  • +4 +/
    > Тебе оно мешает? Не хочешь - не используй.

    А давайте wine в ядро запхнём! А чего, хочешь используй - не хочешь используй!

     
     
  • 4.11, аноним (?), 15:49, 31/07/2010 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >А давайте wine в ядро запхнём!

    Да вроде как уже (см. longene).
    Правда, не mainstream, что радует.

     
  • 4.19, User294 (ok), 22:37, 31/07/2010 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >А давайте wine в ядро запхнём!

    Не ядерный код -> не запихнем.


     
  • 3.8, KERNEL_PANIC (ok), 14:18, 31/07/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Тебе оно мешает? Не хочешь, не используй

    Так все в ядро пихнуть можно. Оно и так уже раздуто, по самый не могу, даже Линус по этому поводу паникует. Если так дело и дальше пойдет, то ядро скоро гиг и больше весить будит. Кому надо - наложит патч, это не сложно. Я не собираюсь его использовать, для меня это лишнюю опцию при сборке ядра отключать, и повышает время компиляции имхо.

     
  • 3.10, аноним (?), 15:45, 31/07/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >Вреда не принесет, а польза будет явно

    Неа. Пользы по сравнению с tomoyo ноль, а вред может "принестись" запросто.

    Чем больше кода в ядре, там труднее его нормальный аудит, и поэтому добавление каждого KLOC в ядро делает его все более уязвимым.

     

  • 1.12, аноним (?), 16:13, 31/07/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    Вообще, в случае локального/удаленного рута apparmor будет защищать не лучше пресловутого фИгового листика.

    Он же приниципально не котролирует права на mount -bind. Получив возможность запускать код от рута, первым делом биндим /bin, /sbin и т.п. куда-нибудь в тихое местечко, и вуаля - вся система наша, что есть apparmor, что нет его.

    Даже простой tomoyo, при правильной настройке, может очень сильно обломать кайф таким ксакепам. А apparmor - нет, при всем желании.

     
  • 1.17, i (??), 22:32, 31/07/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    почему никто на grsecurity не обращает внимания? что там не так?
    http://www.grsecurity.net/features.php
     
     
  • 2.20, slepnoga (??), 22:47, 31/07/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Там уже можно вилдкард для дир ? Нет - ну запиливаем обратно на сервак без юзверей.
    Или оно уже научилось метить трафик и имеет сервер политик ? То же нет?
    Ну и еще пересобрать всю систему, что для кучи народа совершенно неприемлимо.
    О, девы уже могут писать полтики для грсека или админу все так же надо трахать себе моск
    на каждой отдельной машине , вместо их раздачи по сети ?
     

  • 1.38, segoon (ok), 21:49, 01/08/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    В новости ни слова об OpenWall/*/Linux, хотя первые 2 из трёх возможностей Yama основаны именно в нём:
    http://www.openwall.com/linux/README.shtml

    Documentation/Yama.txt:
    This protection is based on the restrictions in Openwall and grsecurity.

     
  • 1.39, gapsf2 (ok), 06:30, 02/08/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    RSBAC - http://www.rsbac.org/ - гибче и мощнее.
    Но включать в ядро его не хотят.
     
     
  • 2.40, Yuriy (??), 14:48, 02/08/2010 [^] [^^] [^^^] [ответить]  
  • –3 +/
    >RSBAC - http://www.rsbac.org/ - гибче и мощнее.
    >Но включать в ядро его не хотят.

    ну хоть ктото наконец то про него написал из всего сброда что радует:)

     

  • 1.41, Роман (??), 15:18, 02/08/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Отсутствие нормально спроектированной, последовательной подсистемы безопасности в Linux приводит к необходимости вот таких костыльных решений.

    В этом смысле архитектура безопасности Windows не в пример лучше - единый механизм защиты для любого системного объекта.

     
     
  • 2.42, segoon (ok), 17:06, 02/08/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Вы про ACL или ещё что-то? ACL уже давно есть.
     
     
  • 3.44, Роман (??), 19:04, 02/08/2010 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >Вы про ACL или ещё что-то? ACL уже давно есть.

    Для произвольного системного объекта (подлежащего защите) или только для файлов?
    Как насчёт ACL для семафоров, разделяемой памяти (shm)?

     
  • 2.43, segoon (ok), 17:17, 02/08/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >Отсутствие нормально спроектированной, последовательной подсистемы безопасности в Linux приводит к необходимости вот
    >таких костыльных решений.
    >
    >В этом смысле архитектура безопасности Windows не в пример лучше - единый
    >механизм защиты для любого системного объекта.

    Тут, кстати, я полностью верю в закон Дарвина :) Чем больше подсистем безопасности в апстриме (читай - на виду у всех), тем лучше их можно изучить, выявить слабые и сильные места и пр. Если не появится явного лидера, то уже существующие сгладят свои острые углы.

    Вот, к примеру, начало жаркого обсуждения почему _нужны_ несколько security подсистем: http://lkml.org/lkml/2007/10/1/192

    И как вы, мне интересно, нормально спроектируете систему политики безопасности, которая удовлетворяла бы _всех_/почти всех?

     
     
  • 3.45, Роман (??), 19:25, 02/08/2010 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >Чем больше подсистем
    >безопасности в апстриме (читай - на виду у всех), тем лучше
    >их можно изучить, выявить слабые и сильные места и пр. Если
    >не появится явного лидера, то уже существующие сгладят свои острые углы.
    >
    >И как вы, мне интересно, нормально спроектируете систему политики безопасности, которая удовлетворяла
    >бы _всех_/почти всех?

    Я не против модульности в системе безопасности. В конце концов, в Windows это тоже фактически отдельный модуль (Security Reference Monitor) статически влинкованный в ядро.
    Я об общей её архитектуре. Если в Windows продвинутая модель безопасности закладывалась на этапе проектирования (линейка NT), то Linux изначально и by design ограничен unix-моделью, а прордвинутые фишки добавлены задним числом (я бы даже сказал - через задний проход) в виде LSM.

     
     
  • 4.46, segoon (ok), 20:56, 02/08/2010 [^] [^^] [^^^] [ответить]  
  • +/
    А вы в курсе того, на что способна эта unix-модель? Когда она была создана, какие задачи она должна решать (и ведь решает до сих пор!), и где её возможности кончаются?) Вы можете назвать популярные проблемы, которые в классической модели posix не решаются или решаются криво? Правительственные многоуровневые модели прав к таковым не относить.

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

     
  • 4.47, segoon (ok), 21:56, 02/08/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Кстати, про by design... В Windows множество ошибок, в т.ч. безопасности, были именно by design. Если выбирать между много всего, в т.ч. ошибок, и ограниченно, но контролируемо, то я лучше выберу второе.
     

  • 1.52, nagual (ok), 04:19, 05/12/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    В виндовсе в какой то мере соблюдается обратная совместимость с предыдущими версиями. Это очень тяжелое бремя.
     
  • 1.53, Аноним (-), 19:11, 21/03/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А вот и контроилирует без capability sys_admin, mount --bind и pivot_root невоз... большой текст свёрнут, показать
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру