Pseudo User Policy
Материал из ALT Linux Wiki
(исправил протухшую ссылку на SecurePackagingPolicy) |
м (→Удаление пользователя: ...суть плохая идея) |
||
(2 промежуточные версии не показаны) | |||
Строка 16: | Строка 16: | ||
=== Суть policy === | === Суть policy === | ||
- | * Если программа для своей работы не требует прав <code>root</code>, она должна работать | + | * Если программа для своей работы не требует прав <code>root</code>, она должна работать от имени непривелигированного псевдопользователя. |
* При этом разные программы следует запускать от имени индивидуальных псевдопользователей, в случаях, когда программы никак не связаны друг с другом, а именно: | * При этом разные программы следует запускать от имени индивидуальных псевдопользователей, в случаях, когда программы никак не связаны друг с другом, а именно: | ||
** файловая система (общие файлы или каталоги для <tt>IPC</tt>) | ** файловая система (общие файлы или каталоги для <tt>IPC</tt>) | ||
Строка 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 динамически создаваемых пользователей и групп. |
Текущая версия на 17:10, 22 октября 2012
Содержание |
Проблема
Ряду программных пакетов для реализации работы с понижением привилегий (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