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

Материал из ALT Linux Wiki
м (→‎Суть policy: "он имени" -> "от имени")
м (→‎Удаление пользователя: ...суть плохая идея)
 
(не показана 1 промежуточная версия 1 участника)
Строка 53: Строка 53:


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


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

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

42px-Wikitext-ru.svg.png
Эту статью следует викифицировать.
Stub.png
Черновик политики 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

Ссылки