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

Материал из ALT Linux Wiki
(актуализация)
м (→‎Удаление пользователя: ...суть плохая идея)
 
(не показано 8 промежуточных версий 7 участников)
Строка 5: Строка 5:


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


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


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


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


=== Пример заведения псевдопользователя ===
=== Пример заведения псевдопользователя ===
Строка 44: Строка 44:


=== Права на каталоги ===
=== Права на каталоги ===
При упаковке приложений следует уделять должное внимание правам доступа, выставляемым на файлы и директории, принадлежащие этому приложению. Подробно об этом пожно почитать в [http://docs.altlinux.ru/alt/devel/ch01s03.html ALT Linux Secure Packaging Policy]
При упаковке приложений следует уделять должное внимание правам доступа, выставляемым на файлы и директории, принадлежащие этому приложению. Подробно об этом можно почитать в [[SecurePackagingPolicy|ALT Linux Secure Packaging Policy]].


Вкратце:
Вкратце:
* Если в каталог пишет только один псевдопользователь, то 0770 root:_pseudouser_group
* Если в каталог пишет только один псевдопользователь, то <code>0770 root:_pseudouser_group</code>
* Если в каталог пишет не только один псевдопользователь, то если у них нет общих для записи файлов, то 3770, иначе 2770.
* Если в каталог пишет не только один псевдопользователь, то если у них нет общих для записи файлов, то 3770, иначе 2770.
* Если псевдопользователи только читают из каталога, то 0750.
* Если псевдопользователи только читают из каталога, то 0750.
* Если псевдопользователи только открывают файлы из каталога, то 0710
* Если псевдопользователи только открывают файлы из каталога, то 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>


=== Ссылки ===
=== Ссылки ===
Строка 57: Строка 71:
* [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

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

Ссылки