Pseudo User Policy: различия между версиями

Текущая версия от 20:10, 22 октября 2012

Эту статью следует викифицировать.

Черновик политики Sisyphus

Автор(ы) — ?

Проблема

Ряду программных пакетов для реализации работы с понижением привилегий (privilege separation) требуется псевдопользователь (и обычно — соответствующая группа; численное значение — от 1 до 499 согласно принятых норм).

Идея предварительно «забить» всех нужных псевдо в /etc/passwd и /etc/group прямо при создании пакета setup обречена на столкновение с непредвиденными надобностями и серьёзными проблемами с интеграцией изменений — ведь новые версии этих файлов будут установлены как *.rpmnew, а автоматизированные средства сведения изменений не прилагаются.

С другой стороны, идея создавать служебные аккаунты динамически при установке пакета сама по себе чревата несовместимостью uid/gid различных инсталляций, что создаёт вполне реальные проблемы с резервным копированием (восстановлением данных в контексте другого сервера).

Кажется разумным сочетание этих подходов: поддержание списка зарегистрированных UID/GID и реализация добавления «по требованию», но с фиксированными значениями. Для этого требуется написать (обобщить имеющиеся) макросы для проверки коллизий (наличие пользователя с «неправильными» uid/gid, как было с sympa; наличие «реального» пользователя с uid/gid >= 500).

При этом для уменьшения плотности этих самых коллизий предлагается отдавать предпочтение именам вида «_name» для «системных» пользователей и групп.

Суть policy

Если программа для своей работы не требует прав root, она должна работать от имени непривелигированного псевдопользователя.
При этом разные программы следует запускать от имени индивидуальных псевдопользователей, в случаях, когда программы никак не связаны друг с другом, а именно:
- файловая система (общие файлы или каталоги для IPC)
- SYSV IPC
- сигналы, посылаемые процессам
- обобщённо, то, на что распространяются unix permissions

Пример заведения псевдопользователя

%define _pseudouser_user     _foo
%define _pseudouser_group    _foo
%define _pseudouser_home     %_localstatedir/foo

Name: foo
...

%pre
/usr/sbin/groupadd -r -f %_pseudouser_group ||:
/usr/sbin/useradd -g %_pseudouser_group -c 'The foo daemon' \
        -d %_pseudouser_home -s /dev/null -r %_pseudouser_user >/dev/null 2>&1 ||:
...

%files
%dir %attr(0775,root,%_pseudouser_group) %_var/run/%name
%dir %attr(0770,root,%_pseudouser_group) %_localstatedir/%name

Права на каталоги

При упаковке приложений следует уделять должное внимание правам доступа, выставляемым на файлы и директории, принадлежащие этому приложению. Подробно об этом можно почитать в ALT Linux Secure Packaging Policy.

Вкратце:

Если в каталог пишет только один псевдопользователь, то 0770 root:_pseudouser_group
Если в каталог пишет не только один псевдопользователь, то если у них нет общих для записи файлов, то 3770, иначе 2770.
Если псевдопользователи только читают из каталога, то 0750.
Если псевдопользователи только открывают файлы из каталога, то 0710

Удаление пользователя

Удалять псевдопользователей не следует.

В силу специфического порядка выполнения пакетных скриптов в rpm прописанный в %postun userdel при обновлении пакета отработает после %post (с какими угодно useradd) из обновляемого пакета. Результатом будет отсутствие пользователя после установки пакета вообще. Так что пусть уж лучше не удаляются… заодно решать вопросы с «плавающими» правами в условиях отсутствия полиси на фиксирование UID/GID динамически создаваемых пользователей и групп.

Исправление ситуации, если псевдопользователь был удалён

На примере webalizer.spec версии 2.01.10-alt3:

%triggerpostun -- webalizer < 2.01.10-alt3
echo "Fixing permissions after faulty previous package:"
/usr/sbin/groupadd -r -f %webalizer_group ||:
/usr/sbin/useradd -g %webalizer_group -G %apache_group -c 'The Webalizer' \
        -d %webalizer_home -s /dev/null -r %webalizer_user ||:
chown -Rv root:%webalizer_group %webalizer_home %webalizer_html

Ссылки

@@ Строка 16: / Строка 16: @@
 === Суть policy ===
-* Если программа для своей работы не требует прав <code>root</code>, она должна работать он имени непривелигированного псевдопользователя.
+* Если программа для своей работы не требует прав <code>root</code>, она должна работать от имени непривелигированного псевдопользователя.
 * При этом разные программы следует запускать от имени индивидуальных псевдопользователей, в случаях, когда программы никак не связаны друг с другом, а именно:
 ** файловая система (общие файлы или каталоги для <tt>IPC</tt>)
@@ Строка 44: / Строка 44: @@
 === Права на каталоги ===
-При упаковке приложений следует уделять должное внимание правам доступа, выставляемым на файлы и директории, принадлежащие этому приложению. Подробно об этом пожно почитать в [http://docs.altlinux.ru/alt/devel/ch01s03.html ALT Linux Secure Packaging Policy]
+При упаковке приложений следует уделять должное внимание правам доступа, выставляемым на файлы и директории, принадлежащие этому приложению. Подробно об этом можно почитать в [[SecurePackagingPolicy|ALT Linux Secure Packaging Policy]].
 Вкратце:
@@ Строка 53: / Строка 53: @@
 === Удаление пользователя ===
-Удалять псевдопользователей не следует.
+Удалять псевдопользователей ''не следует''.
 В силу специфического [[SpecTips/triggers|порядка выполнения пакетных скриптов]] в rpm прописанный в <code>%postun</code> <code>userdel</code> при обновлении пакета отработает ''после'' <code>%post</code> (с какими угодно <code>useradd</code>) из обновляемого пакета. Результатом будет отсутствие пользователя после установки пакета ''вообще''. Так что пусть уж лучше не удаляются… заодно решать вопросы с «плавающими» правами в условиях отсутствия полиси на фиксирование UID/GID динамически создаваемых пользователей и групп.