Comments 32
При чем тут лейбл Oracle Enterprise Linux?
P.S. за статью спасибо, почитаем.
P.S. за статью спасибо, почитаем.
Ох, прошу простить. Ипользовал его только для визуализации «защищенности» линукса.
Мне показалась уместным такая картинка.
Мне показалась уместным такая картинка.
Вот исторический лейбл SELinux.
Если серьезно, то в основном (только?) им занимается именно компания RedHat.
Если серьезно, то в основном (только?) им занимается именно компания RedHat.
Вы слишком вольно относитесь к визуализаци. Например, это касается и вашей аватарки. Насколько я понимаю, вы никакого отношения к RH не имеете. Вести корпоративный блог, используя на аватаре чужую торговую марку несколько… не красиво.
процесс настройки подсистем безопасности в режиме «мягкой» политики чаще всего весьма тривиален
Пробежав взглядом статью и отложив его в favorites всё-таки не могу согласиться, что описанное выше является «весьма тривиальным».
Каждый раз когда читаю в доках «Отключите SELinux» мне хочется стукнуть по голове чем-нибудь больным, чтоб у человека появилось желание разбираться, а не бездумно отрубать всё незнакомое.
Спасибо за хорошую статью, надеюсь пригодится в жизни.
Спасибо. Очень хорошая статья.
Про AppArmor будете писать?
Я, помнится, именно AppArmor юзал для защиты веб. Результат был отличным 8)
Не претендую на достоверность, но по моему аппармор для тех же задач настраивается проще/удобнее.
+ там есть «обучалка». Про SELinux не знаю. Было бы интересно сравнить их…
Про AppArmor будете писать?
Я, помнится, именно AppArmor юзал для защиты веб. Результат был отличным 8)
Не претендую на достоверность, но по моему аппармор для тех же задач настраивается проще/удобнее.
+ там есть «обучалка». Про SELinux не знаю. Было бы интересно сравнить их…
Спасибо.
Не планировал, но если наберется достаточно запросов, то могу.
Задача сравнения довольно трудоемкая, но реализуемая.
Не планировал, но если наберется достаточно запросов, то могу.
Задача сравнения довольно трудоемкая, но реализуемая.
Очень бы хотелось. Но похоже мало нас :(
Действительно мало. Я о него споткнулся когда у меня самба отказалась работать на сусе, долго не мог понять почему для рута permission denied (в логах). Но потом проникся идеей использования :)
По мне, так в apparmor можно разобраться практически интуитивно, чего не скажешь про selinux прочитав статью :)
По мне, так в apparmor можно разобраться практически интуитивно, чего не скажешь про selinux прочитав статью :)
audit2allow и есть «обучалка». Она генерирует разрешающий конфиг по отлупам в логе аудита.
Ах, если Вы это имели ввиду, то да.
Но я бы рекомендовал научиться писать модули политики самостоятельно.
Для понимания, что же происходит.
Но я бы рекомендовал научиться писать модули политики самостоятельно.
Для понимания, что же происходит.
Гм, она скорее нужна для того, что бы быстро понять что «тянет и дергает» процесс, типа что ему нужно для счастья.
Тогда, для Red Hat более верное решение это setroubleshoot [доступен через стандартный yum].
Это приложение, позволяющее анализировать AVC сообщения.
Оно выдает развернутый human-readable отчет, по какой причине высветилась ошибка.
Так же в отчете будет представлена команда, разрешающая данное взаимодействие.
audit2allow же, в свою очередь, позволяет создавать модули для политики на основе тех же AVC. Но довольно часто это не требуется.
Типовая проблема проблема при работе с SELinux это несоответствие контекстов.
Как и говорил ранее, я тем не менее рекомендую вникать в проблему и стараться разрешить ее наиболее корректными с точки зрения концепции методами.
Это приложение, позволяющее анализировать AVC сообщения.
Оно выдает развернутый human-readable отчет, по какой причине высветилась ошибка.
Так же в отчете будет представлена команда, разрешающая данное взаимодействие.
audit2allow же, в свою очередь, позволяет создавать модули для политики на основе тех же AVC. Но довольно часто это не требуется.
Типовая проблема проблема при работе с SELinux это несоответствие контекстов.
Как и говорил ранее, я тем не менее рекомендую вникать в проблему и стараться разрешить ее наиболее корректными с точки зрения концепции методами.
Конечно надо вникать, я с вами не спорю. Это вообще святое правило =) Так то и strace можно юзать 8)
P.S.
AppArmor после обучения выдает человеко-читаемые конфиги. В чем собственно мой поинт и был, что он поудобнее по настройке (на мой взгляд)… просто я с SLES работал, мне было удобно юзать то что дали =) С Ред Хатом не работал в этом направлении, так что не знаю… может я не прав.
P.S.
AppArmor после обучения выдает человеко-читаемые конфиги. В чем собственно мой поинт и был, что он поудобнее по настройке (на мой взгляд)… просто я с SLES работал, мне было удобно юзать то что дали =) С Ред Хатом не работал в этом направлении, так что не знаю… может я не прав.
audit2allow — это жуткий костыль. Вместо введения нового домена предлагается напихать allow в существующие. Применять его конечно можно, но если уж так, то лучше, пожалуй, начать свой путь с dummy policy, в обратном порядке (%
SELinux — как safe_mode в php. Никто его не любит, все его отключают, половина софта не работает из коробки, архитектурно выглядит, как неустойчивая дырявая куча if-ов, распиханных по всему коду (где-то забытых при этом). В php 5.4 вон одумались, убрали safe_mode…
Вся прелесть стандарных bsd-шных прав доступа — в их простоте (кстати, даже эта простота обманчива, ведь есть множественные членства в группах). Это перекрывает даже недостатки от их неуниверсальности. В сравнении с ACL-ом, которые в ntfs (и поддерживаются в ext3+ тоже, кстати) — небо и земля.
Все IMHO.
Вся прелесть стандарных bsd-шных прав доступа — в их простоте (кстати, даже эта простота обманчива, ведь есть множественные членства в группах). Это перекрывает даже недостатки от их неуниверсальности. В сравнении с ACL-ом, которые в ntfs (и поддерживаются в ext3+ тоже, кстати) — небо и земля.
Все IMHO.
Ой, да ладно. RBAC права простому пользователю понять гораздо проще, чем комбинаторный взрыв членства в группах.
ext3+ не поддерживает NT ACL-ы (в смысле сама ФС может хранить что угодно — благо наконец появились расширенные атрибуты, а вот драйвер файловой системы — никакими подобными проверками не занимается). BSD и XNU — поддерживают подмножество.
ext3+ не поддерживает NT ACL-ы (в смысле сама ФС может хранить что угодно — благо наконец появились расширенные атрибуты, а вот драйвер файловой системы — никакими подобными проверками не занимается). BSD и XNU — поддерживают подмножество.
Мне кажется Вы не вполне верно понимаете значение терминов MAC и DAC (например, во всей статье Вы ни разу не использовали ни одной возможности MAC, хотя и задекларировали преимущество MAC во вступлении). SELinux — это не о преимуществах MAC перед DAC (на пользовательской машине таких преимуществ в общем то нет), это о преимуществах fine grained DAC (хоть и достаточно криво реализованного) над классическими юниксовыми триплетами (да что угодно лучше этого).
Что же до POSIX ACLs — они мало того, что были задепрекейчены самими авторами еще 15 лет назад, так еще и не поддерживаются в линуксе (в смысле там конечно есть что-то, что называется POSIX ACLs, но это не те же самые POSIX ACLs, которые были в черновике 1003.1e, хотя и очень близкие к нему).
Что же до POSIX ACLs — они мало того, что были задепрекейчены самими авторами еще 15 лет назад, так еще и не поддерживаются в линуксе (в смысле там конечно есть что-то, что называется POSIX ACLs, но это не те же самые POSIX ACLs, которые были в черновике 1003.1e, хотя и очень близкие к нему).
А что же тогда такое MAC, если не централизованный fine grained DAC?
Оранжевая книга определяет DAC как (взял из «B1», где впервые встречаются и DAC и MAC):
А MAC вот так:
То есть TCSEC (который в общем то и популяризовал эти термины) определяет MAC просто как MLS (Белл-ЛаПадула, который АБСОЛЮТНО бесполезен домашнему пользователю, как впрочем и подавляющему большинству серверов в отличие от, скажем, контроля целостности по Биба).
Надо признать, что трактовка весьма узкая, но самая широкая трактовка, из всех что я когда либо видел, просто утверждала, что MAC — это система где ВСЕ решения о назначении объектам прав производится security officer-ом (не уверен как перевести). Обычные виндовые DACL не подходят по такой трактовке только в плане назначения доступа к объектам, «принадлежащим» субъекту (например, созданным им). Почему это важно для работы с гостайной, думаю, объяснять не нужно. Зачем это может понадобиться домашнему пользователю ума не приложу.
3.1.1.1 Discretionary Access Control
The TCB shall define and control access between named users and
named objects (e.g., files and programs) in the ADP system.
The enforcement mechanism (e.g., self/group/public controls,
access control lists) shall allow users to specify and control
sharing of those objects by named individuals, or defined groups
of individuals, or by both, and shall provide controls to limit
propagation of access rights. The discretionary access control
mechanism shall, either by explicit user action or by default,
provide that objects are protected from unauthorized access.
These access controls shall be capable of including or excluding
access to the granularity of a single user. Access permission
to an object by users not already possessing access permission
shall only be assigned by authorized users.
А MAC вот так:
3.1.1.4 Mandatory Access Control
The TCB shall enforce a mandatory access control policy over
all subjects and storage objects under its control (e.g.,
processes, files, segments, devices). These subjects and
objects shall be assigned sensitivity labels that are a
combination of hierarchical classification levels and
non-hierarchical categories, and the labels shall be used as
the basis for mandatory access control decisions. The TCB
shall be able to support two or more such security levels.
(See the Mandatory Access Control Guidelines.) The following
requirements shall hold for all accesses between subjects and
objects controlled by the TCB: a subject can read an object
only if the hierarchical classification in the subject's
security level is greater than or equal to the hierarchical
classification in the object's security level and the non-
hierarchical categories in the subject's security level include
all the non-hierarchical categories in the object's security
level. A subject can write an object only if the hierarchical
classification in the subject's security level is less than or
equal to the hierarchical classification in the object's
security level and all the non-hierarchical categories in the
subject's security level are included in the non-hierarchical
categories in the object's security level. Identification
and authentication data shall be used by the TCB to authenti-
cate the user's identity and to ensure that the security level
and authorization of subjects external to the TCB that may be
created to act on behalf of the individual user are dominated
by the clearance and authorization of that user.
То есть TCSEC (который в общем то и популяризовал эти термины) определяет MAC просто как MLS (Белл-ЛаПадула, который АБСОЛЮТНО бесполезен домашнему пользователю, как впрочем и подавляющему большинству серверов в отличие от, скажем, контроля целостности по Биба).
Надо признать, что трактовка весьма узкая, но самая широкая трактовка, из всех что я когда либо видел, просто утверждала, что MAC — это система где ВСЕ решения о назначении объектам прав производится security officer-ом (не уверен как перевести). Обычные виндовые DACL не подходят по такой трактовке только в плане назначения доступа к объектам, «принадлежащим» субъекту (например, созданным им). Почему это важно для работы с гостайной, думаю, объяснять не нужно. Зачем это может понадобиться домашнему пользователю ума не приложу.
Интересно, какие права получит пользователь, который успешно проведёт атаку против уязвимого приложения и получит #root:
1) он будет root,
2) или будет root, но с правами запущенного приложения (т.е. с политикой SELinux)?
1) он будет root,
2) или будет root, но с правами запущенного приложения (т.е. с политикой SELinux)?
Sign up to leave a comment.
Введение в SELinux: модификация политики targeted для сторонних веб-приложений