Анатомия SELinux

А есть ли у кого-нибудь из присутствующих опыт по внедрению SELinux на уже существующем и промышленно использующемся сервере?

Давно хотел такой вопрос себе прояснить. Ведь одно дело установить всё из коробочки изначально включив SELinux, допиливая где потребуется, а другое дело внедрить это на существующем сервере.

PS: это можете рассматривать как провокацию

SELinux, как мне кажется, ни разу не операционная система, а ACL. То-есть управлялка доступом и разрешениями всякими. Поправьте.

Ого... ОС SELinux... Пошел искать дистрибутив....:)))))))))

Статья - кокашко. Затронутая тема настолько серьёзна и комплексна, что освещать её подобным образом и по устаревшим материалам - это просто безответственно.

Ничего не написано про модули политики - без них использовать SELinux совсем неудобно, практически невозможно, если вы не эксперт-разработчик SELinux.

IBM_dW, пожалуйста напишите серию статей по AppArmor. SELinux слишком (слишком!) неудобный и сложный в промышленном применении.

Или хотя бы сделайте перевод вот этой статьи - http://developer.novell.com/wiki/index.php/Apparmor_FAQ

где-то читал, что кол-во правил для среднего сервака предприятия - это около 150000 правил. реально ли написать их одному админу?! правда, многое уже настроено "изкоробки", но дописывать ручками под конкретное предприятие немало будет.

> Статья - кокашко. Затронутая тема настолько серьёзна и комплексна, что освещать её подобным образом и по устаревшим материалам - это просто безответственно.

+1. Слишком по верхам прошлись по айсбергу. Была попытка глубинного бурения, но и новичку, и продвинотому эта попытка - как собаке пятая нога... От зачем новичку видеть код? А профи зачем(ему надо - сам в исходниках найдёт)?

Статья - явное наращивание внутриIBMного скора.

>Ничего не написано про модули политики - без них использовать SELinux совсем неудобно, практически невозможно, если вы не эксперт-разработчик SELinux.

Ещё один "плюсадин".

Ну, они-же не будут ВСЕ разные? Частично можно будет использовать куски от других правил, частично положиться на умолчальные значения.

Оказывается, IBM_dW не простой бот. У него есть AI. На лоре есть его три человекоподобных комментария...

>где-то читал, что кол-во правил для среднего сервака предприятия - это около 150000 правил. реально ли написать их одному админу?! правда, >многое уже настроено "изкоробки", но дописывать ручками под конкретное предприятие немало будет.

Дописывать там надо под конкретное приложение/программный комплекс. Если использовать стандартные компоненты стандартно, то можно НАДЕЯТЬСЯ, что подойдут "изкоробочные" правила.

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

У кого есть опыт - поделитесь, что и как, ПОЖАААЛУЙСТА...

а вот у меня вопрос: есть ли визуальные среды разработки политик безопасности? чтобы можно было задать обьекты, отношения и тд и чтобы все красиво - со стрелочками и квадратиками.
и есть ли вообще какой-либо графический язык представления политик безопасности - типа УМЛ?
интересная тема. мож собраться кодерам и спецам по безопасности, чтобы накропать такую: на входе схема безопасности - на выходе готовый файл для СЕЛинукса....

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

В качестве примеров - dbus, X сервер, gconf (кажется так назывался), ещё слышал, но не видел PostgreSQL.

Эта фича очень заманчива - вам не нужно придумывать реализацию системы разграничения доступа - нужно только спросить SELinux 'можно("объект X", "объект Y", "действие Z")?'. Правда придётся вести отображение объектов внутри своей программы на идентификаторы объектов SELinux.

Понапридумывали блин проблем каких то на ровном месте. Ставьте Fedora или RedHat и не парьтесь. Если SElinux искоробочный ругается, 99.99999999999 вероятность что вы чтото делаете очень очень рискованым способом. И нефиг сразу писать разрешающие правила. Безопасность простая не бывает. Последний пример такого "селинукс сакс сделайте мне чудо правило разрешающее мне делать ..." описан в блоге http://danwalsh.livejournal.com/25265.html

> а вот у меня вопрос: есть ли визуальные среды разработки политик безопасности? чтобы можно было задать обьекты, отношения и тд и чтобы все красиво - со стрелочками и квадратиками.

Есть, одна-две входит в поставку. Оценить не берусь. IMHO немного не то, что Вы имеете ввиду, а просто GUI редактор к конфигурации.

> и есть ли вообще какой-либо графический язык представления политик безопасности - типа УМЛ? присоединяюсь к вопросу!

>Есть, одна-две входит в поставку. а как называется? где можно глянуть?

<troll>

ждем продолжения серии, а именно

Физиология SELinux
Патологическая анатомия и физиология SELinux
Пропедевтика болезней SELinux


потому что без полного знания вопроса не никак )

</troll>

>Оказывается, IBM_dW не простой бот. У него есть AI. На лоре есть его три человекоподобных комментария...

Ура! IBM_dW прошёл тест Тьюринга! :)

В общем случае если нужно изолировать приложение(например апач) намного проще использовать виртуализацию.

> SELinux <...> данная операционная система.

O_o

И это всё? Единственное полезное в данной статье - это ссылки на ресурсы в конце оной..

>Оказывается, IBM_dW не простой бот. У него есть AI. На лоре есть его три человекоподобных комментария...

Это легенда, созданная разработчиками.

Ого... ОС SELinux... Пошел искать дистрибутив....:))))))))) sidor (*) (23.10.2008 15:14:53)

Не нужно искать - Slackware рулит!

Ходят слухи, Novell решил AppArmor закопать?

AppArmor уже мертв, в следующий Suse Linux уже будет включен SELinux. А вообще, AppArmor и SELinux бедны отсутствием возможностей обучения. Японцы в этом плане продвинулись дальше.

> AppArmor уже мертв, в следующий Suse Linux уже будет включен SELinux.

Ага, и будет Su SELinux!

Господа C-программеры. 

Объясните, почему вот в этом коде:

static int selinux_socket_create(int family, int type,
                                 int protocol, int kern)
{
        int err = 0;
        struct task_security_struct *tsec;

        if (kern)
                goto out;

        tsec = current->security;
        err = avc_has_perm(tsec->sid, tsec->sid,
                           socket_type_to_security_class(family, type,
                           protocol), SOCKET__CREATE, NULL);

out:
        return err;
}

Сначала объявляется структура: 
struct task_security_struct *tsec;

А только потом проверяется: а не выйти ли нам из функции прямо сейчас?
if (kern) goto out;

Не логично ли было бы с этом случае выйти до всяких упоминаний о 
какой-либо структуре?
Я понимаю, что разработчики ядра знают C, мягко говоря, получше меня,
собственно, потому и вопрос.

Потому, что в Стандарте С переменные описываются в начале функции.

И только в C99 разрешено действовать иначе. Но С99 для ядра - не труЪ.

То есть существуют компиляторы которые, увидев вместо того кода:
        if (kern)
                goto out;

        struct task_security_struct *tsec;

поведут себя неправильно?

В любом случае, спасибо за разъяснение.

Я бы хотел использовать и то и то. Какую из систем безопасности первую подружат с OpenVZ, ту я и буду использовать. Хотя вполне можно selinux|grsec|apparmor + xen использовать уже сейчас. Но слишком громоздко для моих целей.

> Сначала объявляется структура: struct task_security_struct *tsec; А только потом проверяется: а не выйти ли нам из функции прямо сейчас? if (kern) goto out;

А потому что при компиляции то, что вы называете "объявляется структура" выльется в манипуляцию с регистром-верхушкой стека, причём в целях оптимизации эта манипуляция будет одна общая для tsec и для err.

то есть для всех них выделится место на стеке за один раз при входе в блок функции, и не важно, опишете ли вы их позже или раньше.

Нюансы могу возникнуть только в случае с переменными, объявленными внутри вложенного блока: { int a,b,c; } Эти переменные могут попасть в одну кучу с переменными, объявленными в блоке функции, а могут, например, выделиться только при попадании на начало такого блока - здесь всё зависит от компилятора.

Ваш вопрос уместен только в том случае, если выделение памяти под переменные внутри функции происходит по мере исполнения этой функции. Возможен вариант, что ваш компилятор C делает именно так, но это несколько странно...

То есть, в обоих случаях при встрече такого:
static int selinux_socket_create(int family, int type,
                                 int protocol, int kern)
{
        int err = 0;
        struct task_security_struct *tsec;

        if (kern)
                goto out;
out:
        return err;
}

или такого кода:
static int selinux_socket_create(int family, int type,
                                 int protocol, int kern)
{
        int err = 0;

        if (kern)
                goto out;

        struct task_security_struct *tsec;
out:
        return err;
}

компилятор создаст одинаковый код, который за один раз произведет
"манипуляцию с регистром-верхушкой стека" для обоих переменных,
а только затем "вернется" и присвоит err=0? 

>У кого есть опыт - поделитесь, что и как, ПОЖАААЛУЙСТА...

Чем делиться-то?
Если у тебя не RH/Fedora, использовать его пока просто не реально.
RHEL(CentOS) 4/5 тоже сильно отличаются в использовании.
В RH4 проще его выключить.:)
В 5 ставишь пакет selinux-policy-devel и смотришь на примеры политик. Писать тысячи правил нет необходимости, там все делается на готовых макросах.

На боевой сервер и не думайте ставить!
Политики безопастности не всегда нормально работают (опыт на генту)
Чужие политики (шапка) под сервисы надо переписывать
В результате система работающая, а exim c mysql запустить не удалось
А если еще изменится версия-то можно увольнятся

>Анатомия SELinux

опыт паталогоанатома

в 3 томах

> На боевой сервер и не думайте ставить!

Почему это? Я на куче серверов давно использую, все отлично работает.. Правда, сервера на шапке и центоси (пятерке). Дополнительно на некоторых требуется небольшое количество (не больше 50, обычно 0-10) разрешений. Но на четверке проще вырубить, чем разбираться.

Есть ли тут люди активно применяющие SELinux на production?

> Есть ли тут люди активно применяющие SELinux на production?

Есть, конечно

любой не C99 компилятор (а попроси-ка gcc -ansi -pedantic). да и вообще, «размазывать» переменные по функции — не Ъ. если надо — их лучше упрятывать в кодоблоки, но не размазывать по коду как кетчуп по спагетти.

google «function prologue», «function epilogue».