Pseudo User Policy

Материал из ALT Linux Wiki

(Различия между версиями)
Перейти к: навигация, поиск
(согласование uid-gid)
(актуализация)
Строка 1: Строка 1:
-
{{Викифицировать}}
+
{{викифицировать}}
{{DraftPolicy
{{DraftPolicy
|responsible=?
|responsible=?
}}
}}
-
 
-
== Создание псевдопользователей ==
 
-
__TOC__
 
=== Проблема ===
=== Проблема ===
Строка 18: Строка 15:
При этом для уменьшения плотности этих самых коллизий предлагается отдавать предпочтение именам вида «_name» для «системных» пользователей и групп.
При этом для уменьшения плотности этих самых коллизий предлагается отдавать предпочтение именам вида «_name» для «системных» пользователей и групп.
-
=== Заведение псевдопользователей ===
+
=== Суть policy ===
-
Если для нормальной работы пакета приходится создавать псевдопользователя, следует обсудить вопрос в devel@ — могут быть непредвиденные проблемы с доступностью или беспроблемностью имени, uid/gid или настройкой аккаунта.
+
* Если программа для своей работы не требует прав root, она должна работать он имени непривелигированного псевдопользователя.
-
<!-- взято с TypicalPackagingErrors/UserDel -->
+
* При этом разные программы следует запускать от имени индивидуальных псевдопользователей, в случаях, когда программы никак не связаны друг с другом, а именно:
 +
** файловая система (общие файлы или каталоги для IPC)
 +
** SYSV IPC
 +
** сигналы, посылаемые процессам
 +
** обобщённо, то, на что распространяются unix permissions
-
=== Переписка ===
+
=== Пример заведения псевдопользователя ===
-
<pre>> В процессе обсуждения упаковки jabber-пакетов возник такой дискуссионный
+
<pre>
-
> вопрос: есть серверы, есть компоненты - под какими unix-пользователями
+
%define _pseudouser_user    _foo
-
> их запускать?
+
%define _pseudouser_group    _foo
-
>
+
%define _pseudouser_home    %_localstatedir/foo
-
> Я лично придерживаюсь мнения, что это все абсолютно отдельные, ничем не
+
-
> связанные сервера и есть смысл держать их под отдельными пользователями
+
-
> (jabberd2, ejabberd, jabber-jit, jabber-mrim и т.п.) - у них у каждого
+
-
> собственные спулы, собственные логи и т.п.
+
-
>
+
-
> pma@ в личной беседе озвучил противоположную мысль - а не завести ли нам
+
-
> единого пользователя, например, "jabber", которые будет владеть всеми
+
-
> каталогами всех jabber-related пакетов, и под которым, собственно, будут
+
-
> запускаться все сервисы?
+
-
>
+
-
> У кого какие мнения есть на этот счет?
+
-
Если сервера не связанные, то и псевдопользователи должны быть не связанные.</pre>
+
Name: foo
-
''[http://lists.altlinux.org/pipermail/devel/2007-March/043675.html ldv@]''
+
...
-
<pre>В данном случае под связью имеется в виду
+
%pre
-
- файловая система (общие файлы или каталоги для IPC)
+
/usr/sbin/groupadd -r -f %_pseudouser_group ||:
-
- SYSV IPC
+
/usr/sbin/useradd -g %_pseudouser_group -c 'The foo daemon' \
-
- сигналы, посылаемые процессам
+
        -d %_pseudouser_home -s /dev/null -r %_pseudouser_user >/dev/null 2>&1 ||:
-
короче говоря, то, на что распространяются unix permissions.</pre>
+
...
-
''[http://lists.altlinux.org/pipermail/devel/2007-March/043688.html ldv@]''
+
-
<pre>> > > Можно заводить пользователя _tremulous и
+
%files
-
> > > группу _tremulous или нет? И если можно -- с какими uid/gid?
+
%dir %attr(0775,root,%_pseudouser_group) %_var/run/%name
-
> > > Автогенерируемые, как я понял? Доп. разрешение нужно у кого-нибудь
+
%dir %attr(0770,root,%_pseudouser_group) %_localstatedir/%name
-
> > > на этот счет запрашивать?
+
</pre>
-
> > Если автогенерить, то втиснуть uid/gid до 500 желательно...
+
-
> Это то понятно, это и в полиси написано: http://www.altlinux.org/UidGid
+
-
>
+
-
> А вот как именно раздавать -- согласовывая номер с ответственным или же
+
-
> автоматически (похоже, что именно этот вариант, судя спекам других
+
-
> пакетов) -- неясно.
+
-
 
+
-
Согласовывать не надо, useradd выполнит необходимую работу сам.
+
-
Более-менее актуальный пример есть в пакете iftop.</pre>
+
-
''[http://lists.altlinux.org/pipermail/devel/2008-September/078918.html ldv@]''
+
=== Права на каталоги ===
=== Права на каталоги ===
-
См. [http://docs.altlinux.ru/alt/devel/ch01s03.html ALT Secure Packaging Policy], но вкратце:
+
При упаковке приложений следует уделять должное внимание правам доступа, выставляемым на файлы и директории, принадлежащие этому приложению. Подробно об этом пожно почитать в [http://docs.altlinux.ru/alt/devel/ch01s03.html ALT Linux Secure Packaging Policy]
-
<pre>> Мне отсюда не видно, но обычно в таких ситуациях
+
-
> %dir %attr(2770,root,asterisk) %_localstatedir/asterisk
+
-
Если в каталог пишет только один псевдопользователь, то 0770.
+
-
Если в каталог пишет не только один псевдопользователь, то
+
-
  если у них нет общих для записи файлов, то 3770, иначе 2770.
+
-
 
+
-
Если псевдопользователи только читают из каталога, то 0750.
+
-
Если псевдопользователи только открывают файлы из каталога, то 0710.</pre>
+
-
''[http://lists.altlinux.org/pipermail/devel/2007-April/044602.html ldv@]''
+
-
=== TODO ===
+
Вкратце:
-
* ссылки на sympa.spec, webalizer.spec, bugzilla, обсуждения в devel@/sisyphus@
+
* Если в каталог пишет только один псевдопользователь, то 0770 root:_pseudouser_group
 +
* Если в каталог пишет не только один псевдопользователь, то если у них нет общих для записи файлов, то 3770, иначе 2770.
 +
* Если псевдопользователи только читают из каталога, то 0750.
 +
* Если псевдопользователи только открывают файлы из каталога, то 0710
=== Ссылки ===
=== Ссылки ===
-
* [[Документация/ПраваГруппПользователей|Описание назначения некоторых групп]]
 
* [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]

Версия 06:36, 10 сентября 2008

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

Ссылки

 
Личные инструменты