The OpenNET Project / Index page

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

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

Джеймс Моррис (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
Тип: Интересно / К сведению
Ключевые слова: linux, kernel, apparmor, yama, security, lsm
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение Ajax/Линейный | Раскрыть все сообщения | 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 +/
    Только в настройке геморроен и если кто считает что селинуху нельзя поднасрать -... весь текст скрыт [показать]
     
     
  • 6.26, аноним (?), 00:18, 01/08/2010 [^] [ответить]     [к модератору]  
  • +2 +/
    Видимо, вы просто плохо понимаете, как работает Linux Контейнеры дают ровно так... весь текст скрыт [показать]
     
     
  • 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 +/
    Да не настолько уж и больше Зависит от конкретики, конечно Кстати думается что... весь текст скрыт [показать]
     
     
  • 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 +/
    Главный плюс AppArmor в том, что с ней можно разобраться за 5 минут, там очень п... весь текст скрыт [показать]
     
     
  • 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 [^] [ответить]     [к модератору]  
  • +/
    Админа, который полез в серьезный продакшен, не затруднив себя изучением основ р... весь текст скрыт [показать]
     
     
  • 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 +/
    AppArmor не ставит перед собой глобальных целей, он просто позволяет не дать зап... весь текст скрыт [показать]
     
     
  • 7.24, аноним (?), 23:50, 31/07/2010 [^] [ответить]     [к модератору]  
  • +2 +/
    Так должна работать нормальная система MAC, например, selinux в targeted-режиме ... весь текст скрыт [показать]
     
  • 6.28, StrangeAttractor (ok), 02:59, 01/08/2010 [^] [ответить]     [к модератору]  
  • –3 +/
    Рискну высказать своё некомпетентное в уме не е-у ни байта ни про SELinux ни пр... весь текст скрыт [показать]
     
  • 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:
    Заголовок:
    Текст:


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