Pseudo User Policy
Материал из ALT Linux Wiki
(Различия между версиями)
(→согласование uid-gid) |
м (→Удаление пользователя: ...суть плохая идея) |
||
| (9 промежуточных версий не показаны.) | |||
| Строка 1: | Строка 1: | ||
| - | {{ | + | {{викифицировать}} |
{{DraftPolicy | {{DraftPolicy | ||
|responsible=? | |responsible=? | ||
}} | }} | ||
| - | |||
| - | |||
| - | |||
=== Проблема === | === Проблема === | ||
| - | Ряду программных пакетов для реализации работы с понижением привилегий (privilege separation) требуется псевдопользователь (и обычно — соответствующая группа; численное значение — от 1 до 499 согласно принятых норм). | + | Ряду программных пакетов для реализации работы с понижением привилегий (<tt>privilege separation</tt>) требуется псевдопользователь (и обычно — соответствующая группа; численное значение — от 1 до 499 согласно принятых норм). |
| - | Идея предварительно «забить» всех нужных псевдо в < | + | Идея предварительно «забить» всех нужных псевдо в <code>/etc/passwd</code> и <code>/etc/group</code> прямо при создании пакета <code>setup</code> обречена на столкновение с непредвиденными надобностями и серьёзными проблемами с интеграцией изменений — ведь новые версии этих файлов будут установлены как <code>*.rpmnew</code>, а автоматизированные средства сведения изменений не прилагаются. |
С другой стороны, идея создавать служебные аккаунты динамически при установке пакета сама по себе чревата несовместимостью uid/gid различных инсталляций, что создаёт вполне реальные проблемы с резервным копированием (восстановлением данных в контексте другого сервера). | С другой стороны, идея создавать служебные аккаунты динамически при установке пакета сама по себе чревата несовместимостью uid/gid различных инсталляций, что создаёт вполне реальные проблемы с резервным копированием (восстановлением данных в контексте другого сервера). | ||
| - | Кажется разумным сочетание этих подходов: поддержание списка зарегистрированных UID/GID и реализация добавления «по требованию», но с фиксированными значениями. Для этого требуется написать (обобщить имеющиеся) макросы для проверки коллизий (наличие пользователя с «неправильными» uid/gid, как было с sympa; наличие «реального» пользователя с uid/gid >= 500). | + | Кажется разумным сочетание этих подходов: поддержание списка зарегистрированных <tt>UID</tt>/<tt>GID</tt> и реализация добавления «по требованию», но с фиксированными значениями. Для этого требуется написать (обобщить имеющиеся) макросы для проверки коллизий (наличие пользователя с «неправильными» <tt>uid</tt>/<tt>gid</tt>, как было с <code>sympa</code>; наличие «реального» пользователя с <tt>uid</tt>/<tt>gid</tt> >= 500). |
| - | При этом для уменьшения плотности этих самых коллизий предлагается отдавать предпочтение именам вида | + | При этом для уменьшения плотности этих самых коллизий предлагается отдавать предпочтение именам вида «<code>_name</code>» для «системных» пользователей и групп. |
| - | === | + | === Суть policy === |
| - | Если для | + | * Если программа для своей работы не требует прав <code>root</code>, она должна работать от имени непривелигированного псевдопользователя. |
| - | < | + | * При этом разные программы следует запускать от имени индивидуальных псевдопользователей, в случаях, когда программы никак не связаны друг с другом, а именно: |
| + | ** файловая система (общие файлы или каталоги для <tt>IPC</tt>) | ||
| + | ** <tt>SYSV</tt> <tt>IPC</tt> | ||
| + | ** сигналы, посылаемые процессам | ||
| + | ** обобщённо, то, на что распространяются <tt>unix permissions</tt> | ||
| - | === | + | === Пример заведения псевдопользователя === |
| - | <pre> | + | <pre> |
| - | + | %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 | |
| - | + | </pre> | |
| - | + | ||
| - | + | ||
| - | + | ||
| - | + | ||
| - | + | ||
| - | + | ||
| - | + | ||
| - | + | ||
| - | + | ||
| - | + | ||
=== Права на каталоги === | === Права на каталоги === | ||
| - | + | При упаковке приложений следует уделять должное внимание правам доступа, выставляемым на файлы и директории, принадлежащие этому приложению. Подробно об этом можно почитать в [[SecurePackagingPolicy|ALT Linux Secure Packaging Policy]]. | |
| - | + | ||
| - | + | Вкратце: | |
| - | Если в каталог пишет только один псевдопользователь, то 0770 | + | * Если в каталог пишет только один псевдопользователь, то <code>0770 root:_pseudouser_group</code> |
| - | Если в каталог пишет не только один псевдопользователь, то | + | * Если в каталог пишет не только один псевдопользователь, то если у них нет общих для записи файлов, то 3770, иначе 2770. |
| - | + | * Если псевдопользователи только читают из каталога, то 0750. | |
| + | * Если псевдопользователи только открывают файлы из каталога, то 0710 | ||
| + | |||
| + | === Удаление пользователя === | ||
| + | Удалять псевдопользователей ''не следует''. | ||
| - | + | В силу специфического [[SpecTips/triggers|порядка выполнения пакетных скриптов]] в rpm прописанный в <code>%postun</code> <code>userdel</code> при обновлении пакета отработает ''после'' <code>%post</code> (с какими угодно <code>useradd</code>) из обновляемого пакета. Результатом будет отсутствие пользователя после установки пакета ''вообще''. Так что пусть уж лучше не удаляются… заодно решать вопросы с «плавающими» правами в условиях отсутствия полиси на фиксирование UID/GID динамически создаваемых пользователей и групп. | |
| - | + | ||
| - | '' | + | |
| - | === | + | === Исправление ситуации, если псевдопользователь был удалён === |
| - | + | На примере [http://sisyphus.ru/srpm/webalizer/spec webalizer.spec] версии 2.01.10-alt3: | |
| + | <pre>%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</pre> | ||
=== Ссылки === | === Ссылки === | ||
| - | |||
* [https://bugzilla.altlinux.org/show_bug.cgi?id=15268 пример проблемы] | * [https://bugzilla.altlinux.org/show_bug.cgi?id=15268 пример проблемы] | ||
* [https://bugzilla.altlinux.org/show_bug.cgi?id=9895 add useradd and groupadd macros] | * [https://bugzilla.altlinux.org/show_bug.cgi?id=9895 add useradd and groupadd macros] | ||
* [http://lists.altlinux.org/pipermail/devel/2004-January/018128.html http://lists.altlinux.org/pipermail/devel/2004-January/018128.html] | * [http://lists.altlinux.org/pipermail/devel/2004-January/018128.html http://lists.altlinux.org/pipermail/devel/2004-January/018128.html] | ||
* [http://lists.altlinux.org/pipermail/devel/2004-January/018132.html http://lists.altlinux.org/pipermail/devel/2004-January/018132.html] | * [http://lists.altlinux.org/pipermail/devel/2004-January/018132.html http://lists.altlinux.org/pipermail/devel/2004-January/018132.html] | ||
| + | * [https://bugzilla.altlinux.org/show_bug.cgi?id=2623 #2623] | ||
| + | * [https://bugzilla.altlinux.org/show_bug.cgi?id=2977 #2977]. | ||
Текущая версия на 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
