russian fedora summit

...иными словами своеобразный конгресс русских общин

в пятницу 17.07.09 в неформальной обстановке состоялась московская встреча активистов продвижения Fedora в русскоязычном мире. публичные заявления по итогам встречи и её последствия как я понимаю в скором времени будут заметны на сайте проекта.

фотоаппарата как водится в таких случаях ни у кого не оказалось, но не запечатлить момент для истории было нельзя. на фото слева направо (если я ничего не напутал) - Alexander Tiurin, Peter Lemenkov, Alexey Torkhov, Alexey Vasyukov, Inna Kabanova, Viacheslav Kaloshin. я - с другой стороны телефона (этим и определяется качество и размер)

SELinux Lockdown, 10: Заключение

оригинал - SELinux Lockdown Part Ten: Conclusion

Завершение цикла статей по использованию SELinux. Оригинал на английском языке опубликован в блоге Доминика Грифта (Dominick Grift).

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

1. Пользователь SELinux.

По умолчанию сопоставляйте пользователей Linux ограниченному пользователю SELinux. Помните про принцип минимума полномочий. Например, используйте пользователя guest_u: sudo semanage login -m -s guest_u -r s0-s0 __default__

Если необходимо переопределить для новых Linux пользователей пользователя SELinux по умолчанию можно воспользоваться командой useradd и опцией -Z.

Не сопоставляйте пользователей Linux пользователю SELinux unconfined_u. Исключением из этого правила может быть пользователь root. Пользователю root должно разрешаться входить в систему только в экстренных случаях и только через TTY.

2. PAM SEPermit.

Добавьте соответствующие записи для всех ваших ограниченных SELinux пользователях в /etc/security/sepermit.conf, чтобы при работе SELinux в разрешающем (permissive) режиме блокировать их попытки входа в систему .

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

3. Permissive mode против Permissive Domains.

Всегда отдавайте предпочтение использованию разрешающих доменов (Permissive Domains) вместо разрешающего режима (Permissive Mode).

4. Не изменяйте предустановленных по умолчанию пользователей SELinux. Если вам требуется особенный пользователь SELinux и/или пользовательский домен SELinux создайте новый, взяв за основу существующий.

5. Используйте управление доступом на основе ролей (Role based Access control) для ограничения привилегий пользователей, в том числе пользователя root.

6. Не изменяйте существующие роли / домены пользователей.

Если требуется специальная роль, создайте на основе существующей новую и сопоставьте её новому пользователю SELinux. Вместе с тем вы можете сопоставлять существующим ролям новых пользователей SELinux.

7. Используйте команду sudo, вместо su и newrole.

8. Удалите домен(ы) unconfined (неограниченный).

Обязательно сделайте sudo semodule -r unconfined, чтобы отключить системные службы, не имеющие определенных политик. Используйте команду sudo semodule -r unconfineduser, чтобы полностью отключить неограниченную среду пользователя (не рекомендуется). Если вы решили удалить unconfineduser, не забудьте соответствующим образом перенастроить сопоставления пользователей SELinux, чтобы учесть это изменение. Используйте вместо unconfined домен sysadm.

однако, автор отдаёт предпочтение домену unconfined против домена sysadm в качестве дополнительного на все случаи привилегированного пользовательского домена, потому что:

a. для запрета входа неограниченным (unconfined) пользователям можно установить переключатель unconfined_login.
b. не работают переключатели ssh_sysadm_login и xdm_sysadm_login.
c. sysadm - это напившийся (кривой) unconfined.
d. вход пользователю root отключен.
e. домен unconfined используется только как дополнительный привилегированный домен, доступный только при использовании sudo
e.1. за исключением пользователя root, который может входить только в экстренном случае через TTY.

9. Удалите как можно больше политик включением и выключением соответствующих переключателей.

установите unconfined_login в значение off
установите xserver_object_manager в значение on
установите *_exec_content в значение off
рассмотрите применение переключателей secure_mode_*

SELinux Lockdown, 9: Переключатели

оригинал - SELinux Lockdown Part Nine: Booleans

Продолжаю выкладывать перевод цикла статей по использованию SELinux. Оригинал на английском языке опубликован в блоге Доминика Грифта (Dominick Grift).

Переключатели (booleans) это блоки политики, которые можно добавлять или удалять на лету, переключая их значение. Старая примерная политика АНБ (NSA) основывалась на модели минимальных привилегий. Это значит, что разрешалось насколько возможно мало для успешного совершения задания. Почти каждое правило, добавляемое в политику SELinux, добавляет новые привилегии. Для максимального повышения безопасности, обеспечиваемой SELinux, число активных правил следует минимизировать.

В Fedora версии 11 переключателями включены некоторые политики, которые возможно в вашем случае не нужны. Рекомендуется удалять такие политики и добавлять их только при необходимости.

Какие-то переключатели во включенном состоянии добавляют политики, другие добавляют политики в выключенном состоянии. Простое описание функциональности переключателя можно просмотреть командой: sudo semanage boolean -l. Этих описаний обычно достаточно для понимания назначения переключателя, хотя описания короткие. Если пропустить сообщение AVC: denied (Access Vector Cache) через команду audit2why, можно узнать, какой переключатель позволяет устранить эту проблему (если данная проблема может быть решена установкой значения переключателя).

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

Существует три относительно старые утилиты, позволяющие просмотреть, установить и переключить значение SELinux-переключателей: getsebool, setsebool и togglesebool. В Fedora 11 функциональность этих утилит была встроена в команду semanage: semanage boolean.

Имена переключателей должны указывать на модули с исходными текстами, в которых определяются переключатели. К сожалению, часто бывает не так просто найти определение переключателя в исходном тексте политики. В лучшем случае название переключателя начинается с модуля, в котором он определен.

Пример:
Как найти объявление и содержимое переключателя gpg_agent_env_file boolean

# semanage boolean -l | grep gpg
gpg_agent_env_file -> off Allow usage of the gpg-agent --write-env-file option. This also allows gpg-agent to manage user files

Как следует из названия переключателя, он определяется где-то в модуле gpg.te (в данном случае это строки с 196 по 203).

Данный переключатель, будучи включенным, позволяет программам, работающим в SELinux-домене gpg_agent_t, записывать файлы в домашней директории пользователя с обычным типом user_home_t.

Автор предполагает, что в блоке политики имеется ошибка, так как gpg_agent_t может осуществить переход типа (type transition) только для файлов user_home_t и не может для директорий.

Объявление этого переключателя, содержащее краткое описание функциональности, можно найти на строках с 9 по 15.

Описать в рамках данной статьи все переключатели не представляется возможным, поэтому было показано, как в общем случае найти объявление и актуальное описание переключателя. При необходимости ограничения переключателей, можно посмотреть добавляет он или удаляет политику при включении и что фактически он делает. Кроме того, можно включить или выключить переключатель, чтобы определить, нужна ли вам, реализованная им политика. Также при необходимости можно «скормить» имеющиеся сообщения AVC: denied утилите audit2why и посмотреть существуют ли переключатели, позволяющие решить существующую проблему.

Далее рассматриваются некоторые переключатели.

unconfined_login

unconfined_login -> off Allow a user to login as an unconfined domain

Переключатель обсуждался в восьмой части этой серии. Если он установлен в положение on (включен), тогда пользователи могут входить в систему в домене unconfined_t. Можно сильно повысить безопасность установкой его в значение off (выключено). Содержимое переключателя доступно в исходном файле политики unconfineduser.te.

ssh_sysadm_login и xdm_sysadm_login

ssh_sysadm_login -> off Allow ssh logins as sysadm_r:sysadm_t
xdm_sysadm_login -> off Allow xdm logins as sysadm

Переключатель похож на unconfined_login, только имеет дело с доменом sysadm_t. В настоящее время он НЕ работает. Поэтому пока не рекомендуется сопоставлять любых пользователей SELinux роли sysadm_r. Пользователи, имеющие доступ к этой роли, могут сразу входить в систему в привилегированный домен.

*_allow_exec_content_t

allow_sysadm_exec_content -> off allow_sysadm_exec_content
allow_xguest_exec_content -> off allow_xguest_exec_content
allow_user_exec_content -> off allow_user_exec_content
allow_staff_exec_content -> off allow_staff_exec_content
allow_guest_exec_content -> off allow_guest_exec_content

Как видно описание этого переключателя не сильно полезно. Когда переключатель включен пользователям, в соответствующем домене, разрешается запускать их пользовательское содержимое в их собственном окружении. Имеются в виду файлы с типами user_home_t, user_tmp_t или если включены домашние директории nfs или samba типы nfs_t и cifs_t, соответственно. Данные переключатели являются особенностью Fedora, их содержимое можно найти в файле userdomain.if.

secure_module

secure_mode -> off Enabling secure mode disallows programs,
such as newrole, from transitioning to administrative user domains

Переключатель secure_mode можно включить для запрета переходов пользовательских доменов в привилегированные домены. Переключатель определяется в файле selinuxutil.te (строки с 289 по 295).

Пока переключатель работает только для команды newrole и НЕ работает для команды sudo. Поэтому не поощряется рассчитывать на данный переключатель.

secure_mode_insmod

secure_mode_insmod -> off Disable transitions to insmod

При включении данного переключателя для замкнутых (confined) пользователей не разрешается осуществлять доменный переход к домену insmod. Ограниченным пользовательским доменам будет запрещено загружать модули ядра Linux. Переключатель определен в исходном файле modutils.te (политика – строки 120-122, объявление переключателя – строки 4-6).

secure_mode_policyload

secure_mode_policyload -> off boolean to determine whether the system
permits loading policy, setting enforcing mode, and changing boolean values.
Set this to true and you have to reboot to set it back

Описание в принципе понятно. При включении переключателя исключается политика, разрешающая загрузку других политик, изменять режим работы SELinux и изменять значения переключателей. Политика описывается в исходном файле selinux.te (строки с 44 по 52).

xserver_object_manager

xserver_object_manager -> off Support X userspace object manager

Данный переключатель оказывает достаточно сильный эффект. При его включении становится доступным контроль доступа на уровне X сервера. XACE (X Access Control Extension) позволяет оператору настраивать взаимодействие процессов с X сервером. Политика по умолчанию всё ещё имеет определенные шероховатости. XACE реализован для политики безопасности SELinux, реализующей модель Multi Level Security, ориентированной на обеспечение конфиденциальности. В целевой политике (SELinux Targeted Policy) по умолчанию он выключен. Если вам хватает смелости, включите его и опробуйте силу XACE.
После включения переключателя необходимо перезапустить X сервер.

Переключатель описан в файле с исходным текстом политики xserver.te (строки с 749 по 766).

К сожалению, не всегда бывает легко найти, где определяются переключатели. Есть куда стремиться в части именования переключателей.

Вывод:
Для большей безопасности минимизируйте объем политики.
Иногда включением переключателя политика добавляется, иногда политика добавляется выключением переключателя.
Описание переключателя можно просмотреть в исходном тексте политики.

Справка: man getsebool, man setsebool, man togglesebool, man audit2why, man semanage

SELinux Lockdown, 8: Unconfined

оригинал - SELinux Lockdown Part Eight: Unconfined

Продолжаю выкладывать перевод цикла статей по использованию SELinux. Оригинал на английском языке опубликован в блоге Доминика Грифта (Dominick Grift).

Незакрытая (unconfined) область для процессов, которым требуется практически неограниченный (unrestricted) доступ. Почти, потому что не разрешается исполнение (execution) в перезаписываемых областях памяти (writable memory). Для процессов, выполняющихся в незакрытой области, если обратное не определено, ограничены следующие полномочия: Execmem Execstack Execheap Execmod.

прим. перев.: в предыдущих частях термин «unconfined» переводился как «неограниченный», тогда это было не столь принципиально, в этой части близкие термины «(un)confined» и «(un)restricted» встречаются чаще, дабы не превратить всё в масло масленое, для первого термина здесь использую дословное значение.

В установленной по умолчанию Fedora 11 в незакрытом домене (Unconfined Domain) выполняются следующие процессы: ядро Linux, RPM (пакетный менеджер), init scripts (скрипты инициализации) и незакрытые пользователи (unconfined users).
Если иное не определено, незакрытые процессы обычно запускают также незакрытые программы. Предполагается, что незакрытые процессы неограниченны и что потомки наследует это незакрытое окружение. Исключения из этого правила, как было сказано, должны быть определены путём создания политики, определяющей переходы из незакрытого домена в ограниченные области при запуске программ незакрытым процессом.

Можно существенно повысить безопасность, удалив незакрытую область. В результате все процессы будут ограниченны SELinux. В Fedora 11 незакрытую область разделили на две части. Первая часть – незакрытая область для программ, вторая часть – незакрытая область для пользователей. Вторую часть переименовали в «unconfineduser domain».

Результат этого разделения позволяет удалить одно из двух или оба окружения сразу. При удалении домена unconfined, являющегося доменом для незакрытых программ, будут ограничены init-скрипты. В итоге системные службы, для которых не определена политика SELinux, будут запускаться в ограниченном окружении init-скрипта и не будут работать неограниченными. Это отличный способ обеспечить отсутствие в системе неограниченных системных служб. Процессы ядра и RPM останутся незакрытыми (unconfined), потому что этим процессам для нормальной работы требуется слишком много полномочий.

Для обеспечения работы всех операторов в ограниченном окружении можно удалить домен unconfineduser. В случае принятия решения об удалении домена unconfineduser необходимо соответствующим образом изменить конфигурацию сопоставлений SELinux (SELinux mappings).

Если оператор уверенно владеет SELinux (feels comfortable with) не должно быть причин, чтобы не удалить домен unconfined. При необходимости он сможет реализовать политику SELinux для любого системного процесса, не имеющего пока ещё своей политики.

Домен unconfineduser обычно удобнее сохранить, так как оператор имеет возможность вручную определить, каким конкретно пользователям Linux сопоставить этот домен. Настройками SELinux можно не разрешать незакрытые входы в систему через OpenSSH или графический интерфейс пользователя. Это означает, что пользователи имеющие доступ к домену unconfineduser могут входить, используя это окружение, только на TTY (терминал) или получать доступ к незакрытой области посредством команд sudo или su вместе с newrole.

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

Пример:
Удалим домен unconfined, запретим вход незакрытых пользователей, сопоставим роль unconfined_r существующему пользователю SELinux staff_u, удалим пользователю SELinux staff_u роль sysadm_r. Добавим Linux-пользователя John, сопоставим его SELinux-пользователю staff_u и добавим для него запись в файл /etc/sudoers.

sudo setsebool -P unconfined_login off
sudo semanage user -m -L s0 -r s0-s0:c0.c1023 -R "staff_r system_r unconfined_r" -P user staff_u
sudo semodule -r unconfined
sudo useradd -Z staff_u john
sudo visudo (john ALL=(ALL) TYPE=unconfined_t ROLE=unconfined_r ALL)

John входит в систему как ограниченный SELinux-пользователь staff_u. Когда John хочет получить привилегии пользователя root он просто выполняет команду sudo. John может открыть оболочку пользователя root (root shell) в незакрытой области, запустив команду sudo с опцией -s.

Такая конфигурация не должна сильно изменить ваши привычки (ways of doing things), потому что не поощряется вход от имени пользователя root, а ограниченный домен staff_t имеет все необходимые полномочия, требуемые непривилегированному пользователю. Также можно создать собственный домен пользователя, специально под ваши персональные требования и сопоставить его роль специально созданным пользователям SELinux вместе с ролями system_r и unconfined_r. Так вы сможете сохранить в оригинальном виде SELinux-пользователя staff_u и изменять под ваши требования созданные домен и пользователя SELinux.

Вывод:
Обдумайте удаление доменов Unconfined и Unconfineduser для повышения безопасности.

Справка: man semanage, man semodule, man visudo, man setsebool, man sudo

SELinux Lockdown, 7: su, newrole, sudo и run_init

оригинал - SELinux Lockdown Part Seven: su, newrole, sudo and run_init

Продолжаю выкладывать перевод цикла статей по использованию SELinux. Оригинал на английском языке опубликован в блоге Доминика Грифта (Dominick Grift).

До выхода Fedora версии 9 пользователям, имеющим доступ к ролям, для смены домена (Domain Transition) нужно было использовать команду newrole. Команду можно установить с пакетом policycoreutils-newrole. Например, пользователь запускал: newrole -r, и получал приглашение на ввод его пароля. После чего команда newrole проверяла, что у пользователя имеются все необходимые права доступа для осуществления запрашиваемого доменного перехода, и разрешала или запрещала его.

При переходе в привилегированный пользовательский домен и желании выполнить какое-то привилегированное задание пользователь выполнял команду su, чтобы выполнить требования дискреционного контроля доступа (Discretionary Access Control). Команда su запрашивает пароль пользователя root.

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

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

Таким образом получается много команд и паролей всего лишь, например, для перезапуска Apache.

В Fedora версии 9 для поддержки доменных переходов модифицировали команду sudo. Рекомендуется вместо команд su и newrole использовать sudo.
Два основных преимущества команды sudo заключаются в том, что данная команда позволяет за одно действие сменить идентификатор (uid) пользователя Linux и сменить домен SElinux, а также не требуется вводить пароль пользователя root при условии, что ваш пользователь добавлен в конфигурационный файл /etc/sudoers.

Целевой домен может быть указан опцией -t, целевая роль может быт указана опцией -r. Также в файле конфигурации /etc/sudoers можно настроить автоматическое переключение на определенные роль и домен по умолчанию.

Пример:
Linux пользователь joe входит в систему как SELinux пользователь joe_u. SELinux пользователь joe_u имеет доступ к роли joe_r, а также к ролям webadm_r и system_r. Роль joe_r сопоставлена домену joe_t, который обладает всеми необходимыми полномочиями для входа в систему ограниченного пользователя. Пользовательский домен joe_t в соответствии с политикой имеет доступ к ролям system_r и webadm_r. В файле /etc/sudoers о пользователе joe имеется следующая запись:

joe ALL=(ALL) TYPE=webadm_t ROLE=webadm_r ALL

Эта запись разрешает при запуске команды sudo пользователем joe осуществлять автоматическую смену значений параметров его контекста SELinux, соответственно роли на webadm_r и типа на webadm_t.

При входе пользователя joe в систему он оказывается в домене joe_t. Когда у Джо появляется необходимость запустить службу Apache он просто запускает команду:

sudo service httpd start

Команда sudo изменяет идентификатор (uid) Джо на 0 и автоматически осуществляет смену домена и роли Джо на определенные роль и домен - webadm_r и webadm_t.

Джо также имеет доступ к роли system_r, необходимой для смены пользовательского домена на домен сценария инициализации (Init Script), который запускает httpd в правильном домене. Команда run_init больше не требуется.

Если Джо доступно несколько ролей, он может переопределить роль и домен, указанные в конфигурационном файле sudo, указав опции -r и -t с требуемыми значениями роли и домена в качестве параметров.

Вывод:
Отдавайте предпочтение использованию команды sudo вместо команд su и newrole.
Отдавайте предпочтение предоставлению доступа к роли system_r вместо использования команды run_init.

Справка: man su, man sudo, man newrole, man run_init

SELinux Lockdown, 6: Создание ролей SELinux

оригинал - SELinux Lockdown Part Six: Customized SELinux Roles

Продолжаю выкладывать перевод цикла статей по использованию SELinux. Оригинал на английском языке опубликован в блоге Доминика Грифта (Dominick Grift).

В четвёртой части серии описывался процесс создания пользовательских доменов SELinux. Создание ролей осуществляется очень похожим способом. Как уже отмечалось в предыдущей статье про RBAC: роли это сопоставления к пользовательским доменам (прим. перев.: в оригинале - Roles are mappings to User Domains, в отличии от автора я не живу в Голландии, поэтому более удачного перевода пока не предумал). Какие-то домены пользователей могут использоваться пользователями для входа в систему, потому что эти домены, например, имеют полномочия по доступу к домашней директории пользователя. Такие домены в предыдущей части назывались основными (primary) пользовательскими доменами. Другие домены созданы в качестве дополнительных. Пользователи, используя команды sudo или su вместе с newrole, могут осуществить доменный переход (Domain Transition) к этим дополнительным доменам. Дополнительные домены не могут использоваться для входа в систему.

В этой части будет продемонстрировано как создается такой дополнительный пользовательский домен. Целью является реализовать привилегированную роль SELinux, которой предоставлены полномочия по управлению DNS службой Bind. За основу будет взят пользовательский домен webadm_t, обсуждавшийся ранее. Также будет пересмотрен некоторый материал четвёртой части: Создание пользовательского домена SELinux - чтобы разрешить доступ к новой роли bindadm_r, потребуется изменить основной домен пользователя.

Начнём с создания нового дополнительного домена пользователя с названием bindadm, основанного на предустановленном домене SELinux webadm_t. Новый домен пользователя основан на двух файлах с исходным текстом политики SELinux (SELinux Source Policy): webadm.te и webadm.if

Файлы исходных текстов политики SELinux с расширением ".te" называются Type Enforcement файлы. Файлы с расширением ".if" называются интерфейсными (Interface files). Файлы Type Enforcement содержат описания (Declarations) и политику (Policy), персональные или локальные для данного домена (Domain). Интерфейсные файлы содержат описания и политики, общие для этого домена и других доменов, желающими взаимодействовать с данным доменом.

mkdir ~/bindadm; cd ~/bindadm;
echo "policy_module(bindadm, 0.0.1)" > bindadm.te;
echo "role bindadm_r;" >> bindadm.te;
echo "userdom_base_user_template(bindadm)" >> bindadm.te;
echo "allow bindadm_t self:capability { dac_override dac_read_search kill sys_ptrace sys_nice };" >> bindadm.te;
echo "files_dontaudit_search_all_dirs(bindadm_t)" >> bindadm.te;
echo "files_manage_generic_locks(bindadm_t) >> bindadm.te;
echo "files_list_var(bindadm_t)" >> bindadm.te;
echo "selinux_get_enforce_mode(bindadm_t)" >> bindadm.te;
echo "seutil_domtrans_setfiles(bindadm_t)" >> bindadm.te;
echo "logging_send_syslog_msg(bindadm_t)" >> bindadm.te;
echo "userdom_dontaudit_search_user_home_dirs(bindadm_t)" >> bindadm.te;

Это основное содержимое для привилегированного дополнительного домена пользователя. Исключена политика, специфичная для управления службой Apache.
Теперь добавим политику, специфичную для управления службой Bind. Можно позаимствовать эту политику из исходных текстов политики для Bind. Как уже отмечалось, общая политика располагается в интерфейсных файлах. Это значит, что если мы хотим включить общую политику, относящуюся к Bind, можно посмотреть в соответствующем файле политики bind.if если он доступен:

Начиная со строки 252 в bind.if и заканчивая строкой 305 описывается общая политика, разделяемая модулем Bind для управления службой bind. Для включения этой политики в наш Type Enforcement файл требуется всего лишь добавить вызов этого интерфейса:

echo "bind_admin(bindadm_t, bindadm_r)" >> bindadm.te;

На этом Type Enforcement файл bindadm заканчивается. Далее необходимо обеспечить другим доменам возможность взаимодействия с нашим доменом bindadm_t. Реализуем эту часть политики, взяв за основу файл webadm.if.

echo "## Bind administrator role" > bindadm.if;

echo "########################################" >> bindadm.if;
echo "## " >> bindadm.if;
echo "## Change to the bind administrator role." >> bindadm.if;
echo "## " >> bindadm.if;
echo '## ' >> bindadm.if;
echo "## " >> bindadm.if;
echo "## Role allowed access." >> bindadm.if;
echo "## " >> bindadm.if;
echo "## " >> bindadm.if;
echo "## " >> bindadm.if;
echo "#" >> bindadm.if;
echo "interface(\`bindadm_role_change',\`" >> bindadm.if;
echo " gen_require(\`" >> bindadm.if;
echo " role bindadm_r;" >> bindadm.if;
echo " ')" >> bindadm.if;
echo " allow \$1 bindadm_r;" >> bindadm.if;
echo "')" >> bindadm.if;

Позже общая политика администратора Bind (Bind Administrator Shared policy) будет использоваться в нашем основном специально созданном пользовательском домене SELinux.

Следующим шагом будет создание специализированного пользовательского домена SELinux для обслуживания Bind, разрешающего данному домену осуществлять переход к роли bindadm_r вызовом интерфейса bindadm_role_change. Создаваемый домен SELinux будет основан на пользовательском домене staff_t, описание политики смотрим в файле staff.te

echo "policy_module(bindguy, 0.0.1)" > bindguy.te;
echo "role bindguy_r;" >> bindguy.te;
echo "userdom_unpriv_user_template(bindguy)" >> bindguy.te;
echo "sudo_role_template(bindguy, bindguy_r, bindguy_t)" >> bindguy.te;
echo "ssh_role_template(bindguy, bindguy_r, bindguy_t)" >> bindguy.te;
echo "kernel_read_ring_buffer(bindguy_t)" >> bindguy.te;
echo "kernel_getattr_core_if(bindguy_t)" >> bindguy.te;
echo "kernel_getattr_message_if(bindguy_t)" >> bindguy.te;
echo "kernel_read_software_raid_state(bindguy_t)" >> bindguy.te;
echo "auth_domtrans_pam_console(bindguy_t)" >> bindguy.te;
echo "libs_manage_shared_libs(bindguy_t)" >> bindguy.te;
echo "seutil_run_newrole(bindguy_t, bindguy_r)" >> bindguy.te;
echo "netutils_run_ping(bindguy_t, bindguy_r)" >> bindguy.te;
echo "domain_read_all_domains_state(bindguy_t)" >> bindguy.te;
echo "domain_getattr_all_domains(bindguy_t)" >> bindguy.te;
echo "domain_obj_id_change_exemption(bindguy_t)" >> bindguy.te;
echo "files_read_kernel_modules(bindguy_t)" >> bindguy.te;
echo "kernel_read_fs_sysctls(bindguy_t)" >> bindguy.te;
echo "modutils_read_module_config(bindguy_t)" >> bindguy.te;
echo "modutils_read_module_deps(bindguy_t)" >> bindguy.te;
echo "miscfiles_read_hwdata(bindguy_t)" >> bindguy.te;
echo "term_use_unallocated_ttys(bindguy_t)" >> bindguy.te;

Чтобы разрешенить домену bindguy_t осуществлять переход в ограниченное окружение SELinux bindadm_t, добавим вызов интерфейса bindadm_role_change, определенного в нашем интерфейсном файле bindadm.if:

echo "bindadm_role_change(bindguy_r)" >> bindguy.te;

Можно также автоматически создать сопоставление пользователя SELinux с именем bindguy_u ролям bindguy_r, bindadm_r и system_r. Роль system_r включается, чтобы bindadm_t мог останавить, запустить и перезапустить системную службу bind.

echo "gen_user(bindguy_u, user, bindguy_r system_r bindadm_r, s0, s0 - mls_systemhigh, mcs_allcats)" >> bindguy.te;

Чтобы программы входа знали, что bindguy допустимый пользователь, добавим контексты по умолчанию для этого пользователя, взяв за основу контексты по умолчанию пользователя staff_u:

cp /etc/selinux/targeted/contexts/users/staff_u /etc/selinux/targeted/contexts/users/bindguy_u
sed -i 's/staff/bindguy/g' /etc/selinux/targeted/contexts/users/bindguy_u

Теперь можно собрать и установить обе политики bindguy и bindadm:

make -f /usr/share/selinux/devel/Makefile
sudo semodule -i bindguy.pp bindadm.pp

Далее командой useradd, опцией -Z и параметром bindguy_u можно создать нового пользователя Linux:

sudo useradd -Z bindguy_u bindguy

Для того, чтобы разрешить пользователю bindguy использовать команду sudo для автоматического перехода к Linux пользователю root и SELinux домену bindadm_t, добавим в /etc/sudoers:

echo "bindguy ALL=(ALL) ROLE=bindadm_r TYPE=bindadm_t ALL" >> /etc/sudoers;

При входе пользователя bindguy в систему он оказывается в пользовательском домене bindguy_t, основанном на домене staff_t. Домен bindguy_t может осуществлять переход в домен bindadm_t, используемый с правами root и позволяющий управлять службой Bind.

Например, выполнив следующую команду, пользователь bindguy сможет перезапустить службу bind:

sudo service named restart

Также пользователю bindguy разрешается редактировать различные конфигурационные и файлы информационного наполнения Bind. При этом, например, пользователь bindguy не имеет прав изменить пароль пользователя root.

Примечание: Если вы нашли какие-то ошибки в этом упражнении или у вас есть какие-то вопросы или комментарии, пожалуйста свяжитесь с автором. Спасибо!

Справка: man bind, man semodule, man sudo, man useradd

SELinux Lockdown, 5: SELinux RBAC

оригинал - SELinux Lockdown Part Five: SELinux RBAC

Продолжаю выкладывать перевод цикла статей по использованию SELinux. Оригинал на английском языке опубликован в блоге Доминика Грифта (Dominick Grift).

В первой главе этой серии рассказывалось, что пользователи SELinux сопоставляются пользовательским доменам и компонентам мультикатегорийной безопасности (Multi Category Security - MCS). Эти сопоставления могут настраиваться запуском команды semanage с опцией user. Также сопоставления пользователя SELinux могут автоматически настраиваться вызовом интерфейса gen_user() в файле с исходным текстом модуля Type Enforcement (Type Enforcement Source Module) для вашего домена пользователя.

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

В SELinux роли пользователя (User Roles) - это домены пользователя или пользовательские домены (User Domains). Когда упоминаются роли часто имеется в виду дополнительный (secondary) пользовательский домен пользователя SELinux. Часто роли, предназначенные для использования в качестве дополнительных доменов пользователя, отличаются от основных (primary) доменов. Это объясняется тем, что пользователи Linux фактически не используют для входа в систему роли, созданные как дополнительные домены пользователя, .

Вместо этого пользователи Linux, используя команду sudo или комбинацию команд su и newrole, осуществляют переключение домена или доменный переход (Domain Transition) к их дополнительной роли.

Имейте в виду, что некоторые роли разрабатывались как основные домены пользователей, тогда как другие поддерживают только функциональность дополнительного домена пользователя. Первичные пользовательские домены позволяют пользователю войти в систему, второстепенные домены пользователей могут быть использованы только с командами sudo и su вместе с newrole.

Роль Sysadm
Пример роли, предназначенной для использования в качестве основного домена пользователя

SELinux пользователь sysadm_u сопоставлен роли sysadm_r. Это сопоставление можно увидеть, выполнив команду:

sudo semanage user -l | grep sysadm_u

По умолчанию пользователи Linux, сопоставленные пользователю SELinux sysadm_u, работают с ролью sysadm_r. В этом случае sysadm_r - это основной домен пользователя.

SELinux пользователь staff_u также сопоставлен роли sysadm_r. Основным пользовательским доменом пользователя SELinux staff_u является (роль) staff_r. Контексты по умолчанию, определенные в /etc/selinux/targeted/contexts/users/staff_u, определяют с какими пользовательскими доменами пользователи будут подключаться по умолчанию и с какими пользовательскими доменами пользователи могут войти, указав домен пользователя при входе.

По умолчанию SELinux пользователь staff_u входит в систему в домен пользователя staff_t. Роль sysadm_r, предназначенная для использования в качестве основного домена пользователя, может быть использована при входе, например, следующим образом:

ssh joe/sysadm_r@localhost.localdomain.tld

Также роль sysadm_r может быть использована при переходе домена выполнением команд sudo и su вместе с newrole, как это предусмотрено для дополнительных доменов пользователей.

Пользовательский домен sysadm_t является окружением по умолчанию для SELinux пользователя sysadm_u и предназначен для использования в качестве дополнительного окружения для SELinux пользователя staff_u, хотя даже SElinux пользователь staff_u может настроить подключаемый модуль аутентификации (Pluggable Authentication Module) pam_selinux для использования sysadm_t в качестве его основного домена пользователя.

Роль Webadm
Пример роли, предназначенной для использования в качестве дополнительного домена

В отличии от роли sysadm_r, пользовательский домен webadm_t не может быть использован для непосредственного входа в систему. Вместо этого его необходимо использовать из другого домена пользователя через команды sudo или su вместе с newrole. Пользовательский домен webadm_t не имеет разрешений, необходимых для запуск полноценного окружения пользователя.

Для использования роли webadm_r, её следует сопоставить, например, SELinux пользователю staff_u:

sudo semanage user -m -L s0 -r s0-s0:c0-c1023 -R "staff_r system_r webadm_r" -P user staff_u

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

sudo semanage user -a -L s0 -r s0-s0:c0-c1023 -R "staff_r system_r webadm_r" -P user webadm_u
cp /etc/selinux/targeted/contexts/users/staff_u /etc/selinux/targeted/contexts/users/webadm_u

В этом примере роль webadm_r может быть использована только как дополнительный пользовательский домен по двум причинам. Во-первых, пользовательский домен webadm_t не имеет достаточных полномочий для поддержки полноценного окружения входа в систему. Во-вторых, для нашего пользователя webadm_u за основу файла контекста по умолчанию в /etc/selinux/targeted/contexts/users мы взяли файл контекста по умолчанию пользователя staff_u. В этом файле пользовательский домен webadm_t не является допустимым контекстом, используемым для входа в систему.

Использование ролей для ограничения пользователя Root

Управление доступом на основе ролей (Role Based Access Control) может использоваться для создания разных доменов пользователей с разными правами и назначения этих ролей пользователям SELinux. Хотя RBAC может использоваться как для непривилегированных так и для привилегированных пользователей, чаще его используют для ограничения привилегированного пользователя root.

Например, SElinux пользователь webadm_u, созданный выше, может быть использован для ограничения Linux пользователя root до возможности только управлять окружением Apache. Домен пользователя staff_t - непривилегированный. Это означает, что при работе пользователя root в пользовательском домене staff_t ему не доступны все полномочия root. Пользовательский домен webadm_t - ограниченно привилегированный. При работе пользователя root в пользовательском домене webadm_t ему доступны некоторые ресурсы root, доступ к которым разрешен ограниченным окружением webadm_t.

Например, некоторый пользователь сопоставлен SELinux пользователю webadm_u. Ему также разрешены все полномочия пользователя root в конфигурационном файле /etc/sudoers. При входе этого пользователя в систему по умолчанию ему будет определен пользовательский домен staff_t. Если он выполнит команду sudo как staff_t, то ему, например, не будет разрешено перезапустить службу Apache.

Если он до перезапуска службы, используя команду sudo, совершит переход в домен webadm_t, то у него всё получится:

sudo -r webadm_r -t webadm_t service httpd restart

Если же он попытается, используя команду sudo, изменить пароль пользователя root, то он получит отказ, потому что ни staff_t, ни webam_t не имеют таких привилегий.

Это мощная возможность, означающая, что теперь можно делегировать ограниченные явно заданные привилегии без необходимости раздавать пароль пользователя root.
(прим. перев.: в оригинале у автора написано - It means that it is not possible ("не возможно") to delegate limited specified root privileges without having to share roots password - считаю, что тут явно опечатка, комментарий оставлю до получения ответа автора)

Далее рассказывается о некоторых предустановленных ролях.

Роль guest_r
Пользовательский домен, используемый только в качестве основного. Описание пользователя SELinux guest_u приводится в первой части.

Роль xguest_r
Пользовательский домен, используемый только в качестве основного. Описание пользователя SELinux xguest_u приводится в первой части.

Роль user_r
Пользовательский домен, используемый только в качестве основного. Описание пользователя SELinux user_u приводится в первой части.

Роль staff_r
Пользовательский домен, используемый только в качестве основного. Описание пользователя SELinux staff_u приводится в первой части.

Роль sysadm_r
Этот домен пользователя может быть использован и как основной, и как дополнительный домен. Пользователь SELinux sysadm_u использует sysadm_r в качестве роли по умолчанию, а SELinux пользователь staff_u использует sysadm_r как дополнительную роль. Роль sysadm_r обладает достаточными правами для обеспечения входа пользователей в систему. Пользователь sysadm_u описывается в первой части.

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

Роль unconfined_r
Этот пользовательский домен может быть использован и как основной, и как дополнительный домен. Пользователь unconfined_u описывается в первой части.

Роль webadm_r
Этот пользовательский домен может быть использован только в качестве дополнительного домена. Эта роль не имеет доступа к домашним директориям пользователей и многие другие привилегии, необходимые для обеспечения входа пользователей в систему. Данный домен пользователя обладает необходимыми правами для управления окружением Apache.

Роль logadm_r
Этот пользовательский домен может быть использован только в качестве дополнительного домена. Эта роль не имеет доступа к домашним директориям пользователей и многие другие привилегии, необходимые для обеспечения входа пользователей в систему. Данный домен пользователя обладает необходимыми правами для управления окружением регистрации событий (logging).

Справка: man newrole, man su, man sudo, man semanage

SELinux Lockdown, 4: Создание домена пользователя SELinux

оригинал - SELinux Lockdown Part Four: Customized SELinux User Domain

Продолжаю выкладывать перевод цикла статей по использованию SELinux. Оригинал на английском языке опубликован в блоге Доминика Грифта (Dominick Grift).

В первой главе этой серии рассматривались пользователи SELinux и объяснялись некоторые свойства предопределенных пользователей SELinux. В большинстве сценариев должно хватать возможностей данных профилей. В случае если ни один из предопределенных SELinux пользователей не подходит профилю пользователя Linux можно реализовать новую ограниченную среду под свои определенные требования.

Самый простой способ - взять за основу для нового пользовательского домена SELinux (SELinux User Domain) существующий, а не создавать новый с чистого листа. В этой статье будет показано как создать свой пользовательский домен SELinux на основе ограниченного профиля user_t. Также рассматриваются варианты сопоставления данного пользовательского домена с заданным пользователем SELinux, чтобы данному окружению сопоставить пользователей Linux, как это было описано в главе SELinux Users.

Требуется: добавить ограниченного пользователя в систему с требованиями, которые почти идентичны пользователю SELinux user_u. Особенность заключается в том, что этот пользователь должен иметь возможность просматривать содержимое точки монтирования /var.

Чтобы совершить задуманное необходимо создать новое окружение пользователя SELinux на основе пользовательского домена user_t и установить его в модуль политики SELinux (SELinux Policy Module). Мы можем расширить данный модуль политики, позволив просматривать содержимое директории /var, и мы можем создать сопоставление нового пользовательского домена и нового пользователя SELinux. Чтобы вручную сопоставить новый домен и нового пользователя SELinux, вместо добавления сопоставления непосредственно в сам модуль политики, мы можем использовать команду semanage.

Нам потребуется доступ к исходным текстам политики SELinux (SELinux Source Policy) для использования их в качестве подсказки. В этом примере будут использоваться исходные тексты политики SELinux, свободно доступные по адресу http://oss.tresys.com/projects/refpolicy/browser/trunk/. Хотя в нашем случае использование upstream-версии эталонной политики от Tresys (Tresys Reference Policy) будет достаточным, следует отметить, что в большинстве случаев нужно использовать специфичные для своего дистрибутива исходные тексты политики SELinux.

Сначала посмотрим исходный текст пользовательского домена user_t в тексте политики от Tresys: unprivuser.te

Наш новый пользовательский домен (User Domain) с названием myuser_t будет основан на модуле политики user_t. Для соответствия специфики политики дистрибутива Fedora нужно внести несколько незначительных изменений:

mkdir ~/myuser; cd ~/myuser;
echo "policy_module(myuser, 0.0.1)" > myuser.te;
echo "role myuser_r;" >> myuser.te;
echo "userdom_unpriv_user_template(myuser)" >> myuser.te;

Приведенной выше политикой создается новый ограниченный пользовательский домен SELinux, почти идентичный user_t, сопоставленный по умолчанию пользователю SELinux user_u.

Добавим политику, разрешающую просматривать содержимое точки монтирования /var:

echo "files_list_var(myuser_t)" >> myuser.te;

Сопоставим программно наш пользовательский домен SELinux myuser_t новому пользователю SELinux с названием myuser_u:

echo "gen_user(myuser_u, user, myuser_r, s0, s0)" >> myuser.te;

Заметим, что политика выше аналогична выполнению вручную следующей команды semanage:

sudo semanage user -a -L s0 -r s0-s0 -R myuser_r -P user myuser_u

Политика для созданного пользовательского домена готова. Теперь необходимо из исходной политики собрать бинарный модуль политики SELinux:

make -f /usr/share/selinux/devel/Makefile

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

checkmodule -M -m -o myuser.mod myuser.te
semodule_package -o myuser.pp -m myuser.mod

Установите вновь созданный бинарный модуль политики:

sudo semodule -i myuser.pp

В завершении следует определить для нашего нового SElinux пользователя контекст безопасности SELinux (SELinux Security Contexts) по умолчанию, чтобы программы входа знали какой домен пользователя использовать:

cp /etc/selinux/targeted/contexts/users/user_u /etc/selinux/targeted/contexts/users/myuser_u
sed -i 's/user/myuser/g' /etc/selinux/targeted/contexts/users/myuser_u

Теперь мы можем просто добавить нового Linux пользователя и сопоставить его нашему свежему SELinux пользователю myuser_u командой useradd и опцией -Z или командой semanage и опцией -m.

Вывод:
Вместо редактирования существующих по умолчанию создавайте новых SELinux пользователей и домены пользователей SELinux.

Справка: man semodule, man semanage, man checkmodule, man semodule_package

SELinux Lockdown, 3: Permissive Mode Vs. Permissive Domains

оригинал - SELinux Lockdown Part Three: Permissive Mode Vs. Permissive Domains

Продолжаю выкладывать перевод цикла статей по использованию SELinux. Оригинал на английском языке опубликован в блоге Доминика Грифта (Dominick Grift).

Разрешающий режим SELinux (SELinux Permissive Mode) это состояние, в котором SELinux разрешает нарушения политики SELinux на уровне всей системы. В этом состоянии нарушения политики только регистрируются. Разрешающий режим может быть использован для устранения неполадок и тестирования проблем, связанных с SELinux. Трудности с разрешающим состоянием на уровне всей системы связаны с разумной необходимостью перевода системы в безопасную среду и вывода её из эксплуатации. В некоторых редких случаях можно с целью минимизации рисков, вызванных разрешающим режимом, рассмотреть подключаемый модуль аутентификации (Pluggable Authentication Module) SEPermit, но часто данной меры недостаточно, потому что он только запрещает вход Linux пользователям. Системные службы остаются уязвимы к нарушениям политик.

Недавно с целью устранения данных проблем были представлены разрешающие домены SELinux (SELinux Permissive Domains). С разрешающими доменами можно перевести отдельный домен безопасности SELinux в разрешающее состояние. Используя разрешающие домены можно оставить систему в эксплуатации и, например, запретить доступ к данному домену при помощи IPTables, TCP Wrappers, PAM или используя другие методы.

Для добавления и удаления разрешающих доменов SELinux используется команда semanage. Вам не нужно знать в каком домене безопасности работает процесс, чтобы сделать этот домен безопасности разрешающим доменом. Команда ps с опцией -Z поможет узнать эту информацию.

Пример того как сделать разрешающим домен безопасности с названием httpd_t для Apache:

sudo semanage permissive -a httpd_t

Пример того как сделать домен безопасности с названием httpd_t для Apache снова принудительным:

sudo semanage permissive -d httpd_t

Пример того как используя команду semanage просмотреть разрешающие домены SELinux:

sudo semanage permissive -l

Вывод:
Отдавайте предпочтение разрешающим доменам SELinux, а не разрешающему режиму.
Добавляйте, просматривайте и удаляйте разрешающие домены с использованием команды semanage.

Справка: man semanage, man tcpd, man pam_sepermit, man iptables

SELinux Lockdown, 2: PAM SEPermit

оригинал - SELinux Lockdown Part Two: PAM SEPermit

Продолжаю выкладывать перевод цикла статей по использованию SELinux. Оригинал на английском языке опубликован в блоге Доминика Грифта (Dominick Grift).

В предыдущей статье я обсуждал преимущества сопоставления Linux-пользователей ограниченным SELinux-пользователям. Возможно Вам когда-нибудь понадобится устранить проблемы в системе или решить какие-то вопросы, которые требуют работы SELinux в разрешающем режиме (Permissive Mode).

Разрешающий режим SELinux это состояние, в котором ограничения SELinux не осуществляются. Однако, SELinux регистрирует нарушения политики SELinux, которые бы в нормальном состоянии предотвращались. Воспринимайте разрешающий режим как систему обнаружения вторжений (Intrusion Detection System), тогда как принудительный режим (Enforcing Mode) можно рассматривать как систему предотвращения вторжений (Intrusion Prevention System).

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

Существуют способы минимизировать риски, связанные с разрешающим режимом. Предпочтительным способом является недавно представленная возможность с названием разрешающие домены SELinux (SELinux Permissive Domains). Разрешающие домены будут обсуждаться позже.

Подключаемый модуль аутентификации (Pluggable Authentication Module) с названием SEPermit может также помочь минимизировать незащищенность разрешающего режима.

PAM SEPermit может заблокировать вход Linux-пользователю, когда система работает в разрешающем режиме. Рассмотрим систему, в которой Linux-пользователи ограничены SELinux. Разрешающий режим фактически снимает эти ограничения. Linux-пользователи могут воспользоваться этими преимуществами и получить доступ к ресурсам, которые в ином случае были бы для них не доступны.

PAM SEPermit включен по умолчанию в Fedora 11 в различных файлах в /etc/pam.d/, например, в /etc/pam.d/sshd. Чтобы заблокировать возможность входа Linux-пользователя в разрешающем режиме достаточно в конфигурацию SEPermit, расположенную в /etc/security/sepermit.conf, добавить Linux- или SELinux- пользователей.

Например, при добавлении %user_u в файл sepermit.conf в /etc/security, блокируется вход SELinux-пользователю user_u, при работе системы в разрешающем режиме.

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

В большинстве случаев рекомендуется перенести вашу систему из демилитаризованной зоны на время работ по устранению проблем в разрешающем режиме. Хотя PAM SEPermit может быть полезен в некоторых случаях.

Побробуйте!

Вывод:
Отдавайте предпочтение разрешающим доменам (Permissive Domains) SELinux, а не разрешающему режиму работы SELinux (Permissive Mode).
Если разрешающий режим требуется в промышленной среде на системе с Linux-пользователями, ограниченными с использованием SELinux, поощряется блокировка входа Linux-пользователей с использованием подключаемого модуля аутентификации SEPermit.
Учитывайте, что это окажет влияние только на Linux-пользователей, системные службы не будут защищаться SELinux в разрешающем режиме.

Справка: man pam_sepermit, man setenforce, man getenforce

SELinux Lockdown, 1: пользователи SELinux

оригинал - SELinux Lockdown Part One: SELinux Users

Начинаю выкладывать перевод цикла статей по использованию SELinux. Оригинал на английском языке опубликован в блоге Доминика Грифта (Dominick Grift).

Это первая статья в серии о затягивании конфигурации SELinux для Fedora 11.

В Fedora 11 Linux-пользователи по умолчанию сопоставляются SELinux-пользователю unconfined_u. SELinux-пользователь unconfined_u, в свою очередь, сопоставлен ролям unconfined_r и system_r и всем доступным категориям (compartments) Multi Category Security.

Обе роли unconfined_r и system_r сопоставляются доменам безопасности SELinux. Домены безопасности SELinux - это определенные окружения безопасности для процессов в системе Linux.

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

SELinux-пользователь unconfined_u имеет доступ к роли system_r, чтобы иметь возможность запускать системные процессы в своих доменах безопасности. SELinux-пользователь unconfined_u работает в домене безопасности unconfined_t через роль unconfined_r, которой он сопоставлен.

Команда semanage позволяет добавлять, изменять и удалять сопоставления между Linux- и SELinux-пользователями, так же как и другие настройки, касающиеся управления SELinux. В качестве альтернативы для изменения этих настроек можно использовать system-config-selinux, графический интерфейс к semanage.

Чтобы с помощью команды semanage посмотреть какому SELinux-пользователю по умолчанию сопоставлены Linux-пользователи наберите:

sudo semanage login -l | grep default

результат команды будет каким-то таким:

__default__ unconfined_u SystemLow-SystemHigh

В примере выше Linux-пользователи по умолчанию сопоставлены SELinux-пользователю unconfined_u.

Чтобы изменить это и сопоставить Linux-пользователей по умолчанию ограниченному SELinux-пользователю с именем user_u просто наберите:

sudo semanage login -m -s user_u "__default__"

В результате все новые Linux-пользователи будут по умолчанию сопоставляться ограниченному SELinux-пользователю user_u.

Вы можете переопределить данное сопоставление при добавлении Linux-пользователей командой useradd используя опцию -Z. Эта опция определяет какому SELinux-пользователю должен быть сопоставлен Linux-пользователь.
Например наберите:

sudo useradd -Z guest_u joe

В результате будет создан новый Linux-пользователь с именем joe, который будет сопоставлен SELinux-пользователю guest_u, вместо определенного по умолчанию SELinux-пользователя.

Также для изменения сопоставления между Linux-пользователем и SELinux-пользователем может быть использована команда usermod с опцией -Z.

Существует несколько предопределенных профилей SELinux-пользователей. Список данных профилей можно вывести командой semanage, наберите:

sudo semanage user -l

Далее я рассмотрю некоторые свойства этих предопределенных SELinux-пользователей.

SELinux-пользователь guest_u:
Этот профиль используется для пользователей, которых необходимо усиленно контролировать. SELinux-пользователь guest_u может только войти в систему используя OpenSSH. Гостевые пользователи не имеют доступа к сетевым ресурсам и программам с установленными битами setuid и setgid.

SELinux-пользователь xguest_u:
Данный профиль аналогичен guest_u за исключением того, что xguest пользователи могут входить в Xwindow и не могут входить используя OpenSSH. Другим исключением является то, что данный пользователь может получить доступ к HTTP порту, используя контролируемый SELinux экземпляр Mozilla Firefox.

SELinux-пользователь user_u:
SELinux-пользователь user_u напоминает обычного непривилегированного ограниченного (confined) SELinux-пользователя. Такой пользователь может войти в систему используя Xwindow и OpenSSH, имеет доступ к сетевым ресурсам, но не может использовать программы с установленными битами setuid и setgid.

SELinux-пользователь staff_u:
Этот SELinux-пользователь идентичен user_u, за исключением того, что staff_u может использовать программы с флагами setuid и setgid. Кроме того пользователь staff_u может также просмотреть информацию обо всех процессах в системе и имеет некоторые другие несущественные привилегии по сравнению с пользователем user_u.

SELinux-пользователь sysadm_u:
Данный пользователь придуман, чтобы ограничить используя SELinux учетную запись root, что обычно делать не рекомендуется. Он используется в Multi Level Security окружении, где нет пользователя unconfined_u.

SELinux-пользователь unconfined_u:
SELinux-пользователь unconfined_u это среда, в которой по умолчанию работают все Linux-пользователи в соответствии с целевой политикой Fedora (Fedora Targeted policy). Этот пользователь в значительной степени освобожден от ограничений, накладываемых SELinux. Исключением является механизм Memory Execution Protections (ограничение на исполнение определенных операций в памяти).

Если Вы хотите повысить безопасность вашей системы, тогда не следует сопоставлять реальных Linux-пользователей, не пользователя root, SELinux-пользователю unconfined_u. Во многих сценариях существование неограниченных пользователей создает зияющую дыру в безопасности.

Вход пользователя root должен быть запрещен. root должен иметь возможность войти с терминала только в случае крайней необходимости. В Fedora, Linux-пользователь root сопоставлен unconfined_u. Это означает, что root практически не защищается SELinux.

Чтобы повысить безопасность использования root можно сопоставить пользователя root SELinux-пользователю sysadm_u. Хотя это не сильно увеличивает безопасность по сравнению с unconfined_u и root будет иметь возможность обойти ограничения SELinux.

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

SELinux-пользователь system_u:
Этот пользователь зарезервирован для нужд системы. Обычные Linux-пользователи не должы сопоставляться с SELinux-пользователем system_u.

Как определить SELinux-пользователя по умолчанию для новых Linux-пользователей объяснили, как переопределить сопоставление по умолчанию с использованием команды useradd и опции -Z тоже объяснили.

Выше было рассказано о доступных предопределенных SELinux пользователях. Осталось показать как можно изменить сопоставление SELinux-пользователя Linux-пользователям.

Вывести список всех сопоставлений между Linux- и SELinux- пользователями:

sudo semanage login -l

Сопоставить Linux-пользователя SELinux-пользователю:

sudo semanage login -a (...)

Изменить сопоставление межд Linux-пользователем и SELinux-пользователем:

sudo semanage -m (...)

Удалить сопоставление между Linux-пользователм и SELinux-пользователем:

sudo semanage -d (...)

Вывод:
Для повышения безопасности системы настройте SELinux, чтобы по умолчанию Linux-пользователи сопоставлялись ограниченным SELinux-пользователям.
Запретите вход пользователю root в систему с использованием OpenSSH и Xwindow. Разрешите пользователю root входить только в крайних случаях, используя терминал. Либо оставьте root сопоставленным SELinux-пользователю unconfined_u или сопоставьте его пользователю sysadm_u (например, если вы решите деинсталлировать модуль SELinux unconfineduser).
Сопоставьте ваших Linux-пользователей наиболее подходящим ограниченным профилям SELinux-пользователей.
Используйте команду useradd и опцию -Z, чтобы добавлять Linux-пользователей, переопределяя сопоставление, определенное по умолчанию, передавая имя SELinux-пользователя в качестве аргумента.

Справка: man semanage, man useradd, man usermod

rezlooks-pastelblue

как-то наметил себе посмотреть gtk-тему.

собственно я это сделал.

взяв за основу gtk-тему rezlooks-pastelgreen, сотворил себе тему с созвучным названием rezlook-pastelblue.
как и следует из названия в теме основной тон с зеленного сменил на голубой.

скачать тему

тему для metacity пока не совсем осилил, на снимке тема (слегка уже измененная) GiloucheIM

update: за сутки файл с яндекса скачали 15 раз, для интереса опубликовал тему на gnome-look.org

про приватность...

навеяло новой возможностью, предлагаемой в firefox 3.5 - Private Browsing (а).

почитал политику конфиденциальности относительно google chrome... и рядом... (б)

что-то как-то не проникся я идеей сокрытия данных от сожителей по квартире (а) с одновременным выкладыванием своего "сетевого портрета" на гугле (б)... прямо как в помутнении у Ф. Дика

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

поддержал бы "отечественного производителя", но не удобен мне интерфейс яндекса (хотя почтовый ящик основной на нём)

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

план непутина

1. поковырять gtk-тему см. результат
2. научить decibel читать cue-файлы
3. узнать почему он же не умеет читать файлы с '#' в имени

з.ы. куда-нить надо было повесить... забуду.

How PulseAudio works

как говорится лучше один раз увидеть, чем много раз услышать...

з.ы. согласно комментариям тут это не есть полная архитектура системы... тем не менее... очень наглядно.

Decibel & Monkeys

на сегодняшний день основным плеером в Linux у меня является Decibel Audio Player. плюсы, по которым я его выбирал - он играет музыку и делает это хорошо (по большому счету, больше ничего особенного он делать не умеет, да и не собирается - смотрим сайт проекта).
понятие "хорошо" для меня включает - проиграть музыку, показать кто поет, показать обложку (при необходимости поискать её в сети), рассказать об этом last.fm.

комбайны разнообразных коллекций в формате а-ля айТюнс - rhythmbox, amarok, songbird меня не устраивают просто потому, что я не считаю, что это самый дружественный способ показать мою коллекцию музыки. в этом плане меня больше устраивает подход, реализованный в windows media player.
их основной недостаток - напрягает, когда плеер считает, что он лучше меня знает как организована моя коллекция, не даёт объяснить ему, что он всё таки не прав и главное считает своей главной задачей изменять мои файлы и создавать кучу служебных файлов там где это не нужно.
отдельно не нравится, что плеер, претендующий на роль помощника в навигации по музыкальному массиву, реально усложняет это делать. особенно когда музыки много, а плеер сваливает в кучу файлы с неразпознанными тегами. про магию с кодировками (linux vs unicode vs windows) не говорю.

как-то пользовался quodlibet у него был один косяк со съёмным диском, обходимый, но сильно раздражающий...

так или иначе я перешел на decibel. к чему я всё это настучал?

столкнулся я тут недавно с неудобством - decibel делает вид, что не умеет проигрывать файлы формата MonkeysAudio (те, что с расширением APE).
именно делает, так как за проигрывание отвечает gstreamer, а он это делать умеет. метаданные файлов разбирает библиотека mutagen, которая данный тип также понимает.
а посему открываем исходники, далее:

1. по аналогии, например, с файлом ../src/media/flac.py создаем файл ../src/media/monkeysaudio.py следующего содержания:

from mutagen.monkeysaudio  import MonkeysAudio
from media.track.fileTrack import FileTrack

def getTrack(file):
    """ Return a Track created from a MonkeysAudio APE file """
    track    = FileTrack(file)
    monkeysAudioFile  = MonkeysAudio(file)
    
    track.setLength(int(round(monkeysAudioFile.info.length)))
     
    try:    track.setTitle(str(monkeysAudioFile['title'][0]))
    except: pass

    #и далее по тексту .../flac.py

    return track

2. открываем файл ../src/media/__init__.py и в нем:
- в конце 21 строки from format import asf... дописывем ..., monkeysaudio
- в конце 28 строки в словарь добавляем пару '.ape': monkeysaudio, строка должна выглядеть как-то так (одной строкой):
mFormats = {'.flac': flac, '.m4a': mp4, '.mp3': mp3, '.mp4': mp4, '.mpc': mpc,'.ogg': ogg, '.wma': asf, '.ape': monkeysaudio}

3. сохраняем, запускаем, слушаем.

дополнительное неудобство - decibel не разбирает файлы формата CUE Sheet, что бывает неудобно в случаях когда в наличии flac- или ape-файл без тегов и cue-файлом вместо них. подумаю об этом завтра.