PAM+SELinux, не будут ли перекрывать друг-друга?

ты сравниваешь зелёное со сладким. PAM отлично работает в том числе и совместно с SELinux, и кажется стал настолько де-факто стандартом что ни из одного дистрибутива его удалить нельзя.

SELinux — активно висит в бекграунде и перехватывает любые действия любых процессов. Потом, согласно одному ему ведомой логике эти действия либо разрешает, либо запрещает. Практически как Касперский, только для Linux.

PAM — тупая штука, сама ни за чем не следит. Однако процессы при желании могут к ней обратиться с запросом, является ли какое-либо действие легитимным или нет. Выполняет также другие похожие действия (например процесс вместо того чтобы сам сделать запись в логах может попросить PAM сделать это за него).

>де-факто стандартом что ни из одного дистрибутива его удалить нельзя.

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

PAM — тупая штука, сама ни за чем не следит. Однако процессы при желании

не при желании, а всегда, если что-то собрано с поддержкой PAM , то и обращаться за аутентификацией оно будет чепез PAM , а не напрямую
Кроме того PAM занимается не только аутентификацией, но и например установкой системных ограничений (/etc/security/limits.conf)

Потом, согласно одному ему ведомой логике эти действия либо разрешает, либо запрещает

согласно заданному набору правил ;)

>согласно заданному набору правил ;)

очевидно, это был тонкий намек на то, что описанные политики в селинуксе нетривиальны для чтения, написания и понимания.

Slackware=FreeBSD)))

в BSD своя реализация хранения паролей,
там не используется ни Linux PAM, ни shadow password suite (shadow,libshadow) , в слаке используется Shadow, но не используется PAM

по теме, а что вы собственно пытаетесь сделать? Если построить свой дистрибутив с SELinux, то задача далеко не тривиальна, почему, уже частично обьяснили, нужно писать правила на все и вся.
Обычно лучше взять готовый дистрибутив где дистростроители уже с правилами определились

SELinux — активно висит в бекграунде и перехватывает любые действия любых процессов. Потом, согласно одному ему ведомой логике эти действия либо разрешает, либо запрещает. Практически как Касперский, только для Linux.

Не очень хорошее сравнение — политики SELinux всё же можно читать/писать при некоторой подготовке. Плохо то, что не охвачено очень много программ, а вникать во все эти тонкости и писать недостающие политики самостоятельно — очень невесёлое занятие. По моему нубскому мнению, SELinux хорошо подойдёт для огораживания смотрящих в публичные сети сервисов, для остального — слишком много работы.

А разве можно его использовать «частично», включив только для определенного кол-ва сервисов?

Я пока что пытаюсь получить общее представление. Как ни странно, ни одна статья вменяемого и полного представления не дает. Там нужно долго и нудно вникать, я же хочу оттолкнуться от глабального. А потом уже вникать в то, что будет необходимо.

зависит от политик по умолчанию

)))То что в BSD другая реализация-я в курсе. Я постебался просто))) По архаичности FreeBSD=Slackware. Хотя кому как и для чего, конечно.

А разве можно его использовать «частично», включив только для определенного кол-ва сервисов?

Разумеется. Я сильно не вникал, но правила там очень сильно раздроблены.

Так я не понял, работа PAM и SELinux зависит от политик этих служб по-умолчанию, или все же от политик конкретной настройки?

я же хочу оттолкнуться от глабального

Fedora/RedHat, Debian. В Debian имеется стандартная политика targeted от RH (selinux-policy-default), а также selinux-policy-mls (поддержка ограничена, подойдёт для изучения многоуровневой модели).

Политика SELinux состоит из множества индивидуальных правил для отдельных программ. Насколько я понимаю, некой политики «для всех по умолчанию» там нет.

Можно почитать вводные статьи по PAM и SELinux на ibm.com.

Я бы не советовал пытаться юзать SELinux под дебианом.
Включить enforced mode и не получить полудохлую систему — такой трюк возможен _только_ в редхатовских дистрах.

>Так я не понял, работа PAM и SELinux зависит от политик этих служб по-умолчанию, или все же от политик конкретной настройки?

Работа PAM зависит от настроек PAM, как ни странно это звучит.
Есть там такие магические слова — sufficient и required.

У SELinux можно глобально выбирать выбирать между targeted (все программы, для которых нет правил, работают в домене unconfigured_t и никак не ограничиваются) и strict (запрещено все, что не разрешено явно).

ACL файловой системы входит в PAM?

Нет.

Подскажите, пожалуйста, а какие еще штатные решения и средства существуют в Linux для обеспечения безопасности? Помимо PAM, SELinux, ACL?

> Включить enforced mode и не получить полудохлую систему — такой трюк возможен _только_ в редхатовских дистрах.

я как-то включил на Debian. После этого X-server отказался запускаться даже из-под root O_o :)

>Подскажите, пожалуйста, а какие еще штатные решения и средства существуют в Linux для обеспечения безопасности? Помимо PAM, SELinux, ACL?

Прежде всего стандартные права файловой системы (ACL применяются обычно в довольно сложных случаях, когда гибкости этих прав не хватает).

В качестве более простого аналога SELinux в ядра >=2.6.30 включили TOMOYO 2.x (не путать с веткой 1.x). По простоте настройки эта штука близка к apparmor, но немного превосходит его по возможностям (например, позволяет контролировать контекст вызова, возможность переименования, право делать mount --bind и pivot_root).

Традиционные методы, такие как chroot и сброс привилегий, тоже никто не отменял.

Также для целей безопасности можно использовать контейнеры (openvz, lxc) и виртуальные машины (xen, kvm). Кстати, не так давно читал обзор, что kvm без sVirt'а в целом менее безопасен, чем xen, а с sVirt'ом — уже безопаснее ксена. Но sVirt требует enforced SELinux, так что нигде кроме редхата такое не прокатит.

Ну и советую не забывать про регулярные обновления софта, настройку фаервола, сканеры руткитов, IDS/IPS, анализаторы логов, аудит системных операций, правильную расстановку прав и настройку демонов.

Большое спасибо. Кстати, не подскажите, такие средства как Bastilie и Apparmor используются еще?

>Bastilie

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

Apparmor

apparmor используется в убунте, так как он известен своей предельной простотой, а каноникал ориентирует свой дистрибутив главным образом на неподготовленных пользователей. Правда, они продолжают цепляться за apparmor даже после появления в ядре не менее простого и более мощного tomoyo, но это вполне понятно — лень конфиги переписывать.

Еще apparmor есть в сусе, но там история вообще веселая вышла. Сначала новелл целиком купили фирму, которая разрабатывала apparmor, и добавили ее поддержку в сусю, а через некоторое время они заявили, что основной фокус будут делать на развитии SELinux, а apparmor оставят исключительно для совместимости.

В других дистрибутивах apparmor'а нет, так как он не включен в ядро и требует патчей и пересборки (в отличие от tomoyo и SELinux).

Кстати, сейчас главный разработчик этого чуда работает в microsoft'е, занимается безопасностью винды :)

Спасибо Вам за развернутый ответ. Не зря значит я выбрал CentOS))) Великая ось!