Pseudo User Policy

Проблема

Ряду программных пакетов для реализации работы с понижением привилегий (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

Ссылки

• пример проблемы
• add useradd and groupadd macros
• http://lists.altlinux.org/pipermail/devel/2004-January/018128.html
• http://lists.altlinux.org/pipermail/devel/2004-January/018132.html
• #2623
• #2977.