[devel] NobodySubjectPolicy draft

[devel] NobodySubjectPolicy draft

[Arseny Maslennikov]

[-- Attachment #1: Type: text/plain, Size: 6411 bytes --]

Hi!

(Видимо, потребуется проходить процедуру PolicyPolicy, но писать статью
на вики и воевать с разметкой MediaWiki сейчас некогда, так что начнём
обсуждение этим письмом, а страницу по его тексту составим позже)

=== Введение ===

Как известно, в файле passwd по умолчанию в наших системах присутствуют
пользователь и группа "nobody".

Одно время в кругу разработчиков и администраторов ходила мода считать
этого пользователя наименее привилегированным, будто ему почти ничего
нельзя: в ФС почти нет файлов, ему доступных, у него нет логин-шелла,
под ним нельзя запустить десктоп штатными средствами, ... Из этого
выводили ошибочное следствие, что какой-нибудь нетребовательный
процесс-службу можно запускать прямо под nobody, чтобы отсечь ему доступ
к "более важным" службам. Как только таких сервисов становится больше
одного, оказывается, что все они работают с общими привилегиями, могут
слать друг другу сигналы и т. д., то есть недостаточно изолированы друг
от друга. Им просто следует работать под собственными системными UID, а
концепция "наименее привилегированного uid" не имеет смысла.

В ядре Linux достаточно давно есть понятие overflowuid/overflowgid:
зарезервированное значение uid и gid, которое используется, чтобы
обозначить в одной подсистеме непредставимые значения uid и gid в
файлах из другой подсистемы. Например, в файловых системах с
16-разрядными полями uid и gid вместо невлезающего значения будет
записан overflowuid/overflowgid. Другой пример: NFS-клиент
может представлять рута на клиентской машине overflowuid-ом на сервере.
Разнородные апстримы сходятся на том, чтобы зафиксировать в качестве
этого значения число ((uint16_t)-2), оно же 65534, дефолт в ядре, и
обозвать этого пользователя nobody.

Вообще говоря, под пользователем nobody и группой nobody в системе не
должно работать ничего, а в ФС на несъёмных устройствах хранения не должно
создаваться файловых объектов с такими uid и gid. Для того, чтобы это
гарантировать, следует ввести автоматические проверки на этапе
сборки пакетов, а лучше даже во время работы системы (что-то вроде
seccomp-фильтра на всех процессах, запрещающего setuid и setgid в этого
пользователя), но не всё сразу.

=== Предложение ===

Вношу следующее предложение:
- Сменить пользователю и группе nobody численный идентификатор с 99 на
  65534. Для обозначения 99-го оставить другое имя, например, _nobody99;
- Передать /var/nobody этому самому _nobody99;

Для пакетов в Sisyphus:
- Запретить установку файловых объектов под nobody с пакетами;
- Рекомендовать мейнтейнерам не допускать, чтобы собираемые ими
  системные службы исполняли код под nobody;
- Рекомендовать администраторам не запускать процессы под юзером и группой
  nobody.

=== Footprint ===

Я взялся выявить пакеты, которые по ошибке собираются или
устанавливаются так, чтобы работать под nobody:

- Упоминают username nobody в тексте значащей части спека:
  bozohttpd	george @everybody
  freeipa	slev sem sin
  kf5-kdesu	zerg
 
Все они устанавливают в систему либо файлы под nobody, либо инструкции
для процессов в виде инит-скриптов, юнитов или частей sshd-конфига.

Вот этот пакет зачем-то пытается ставить в систему исполнимый бинарник с setgid nobody:
  kf5-kdesu	zerg
Забавно, что этот бинарник после установки в хешерницу всё же оказывается 2711/root/root.
Я планирую запретить так делать на уровне sisyphus_check.
 
- Используют username nobody при работе и при этом как-то упоминают nobody в спеке:
  checkinstall-helper-sh-safely	imz @everybody
В этом конкретном случае явный вред от того, что checkinstall-нагрузка
работает под nobody, представляется мне малым, но с точки зрения
уменьшения ментальной нагрузки ему лучше тоже иметь своего сист.
пользователя.

Приветствую вопросы и предложения.

Спасибо!

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [devel] NobodySubjectPolicy draft

[Sergey V Turchin]

On Wednesday, 15 November 2023 16:00:56 MSK you wrote:

[...]
> Вот этот пакет зачем-то пытается ставить в систему исполнимый бинарник с
> setgid nobody: kf5-kdesu	zerg
> Забавно, что этот бинарник после установки в хешерницу всё же оказывается
> 2711/root/root.
Там для этого файла хоть 0000, не важно.

> Я планирую запретить так делать на уровне sisyphus_check.
На что сменить? Сделать пользователя kde_nobody?

[...]

-- 
Regards, Sergey.

Re: [devel] NobodySubjectPolicy draft

[Arseny Maslennikov]

[-- Attachment #1: Type: text/plain, Size: 1244 bytes --]

On Wed, Nov 15, 2023 at 04:42:21PM +0300, Sergey V Turchin wrote:
> On Wednesday, 15 November 2023 16:00:56 MSK you wrote:
> 
> [...]
> > Вот этот пакет зачем-то пытается ставить в систему исполнимый бинарник с
> > setgid nobody: kf5-kdesu	zerg
> > Забавно, что этот бинарник после установки в хешерницу всё же оказывается
> > 2711/root/root.
> Там для этого файла хоть 0000, не важно.
> 
> На что сменить? Сделать пользователя kde_nobody?

С точки зрения сабжа — лишь бы не nobody и, если можно, лучше не 99.
Я не пользователь KDE и не знаком с особенностями работы kdesu, но если
можно хоть 0000, то можно и root:root оставить.

А если эта программа реально должна повышать себе группу, например, это
часть её протокола взаимодействия с кем-то, то лучше завести отдельную,
_kdesu какое-нибудь.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [devel] NobodySubjectPolicy draft

[Arseny Maslennikov]

[-- Attachment #1: Type: text/plain, Size: 636 bytes --]

On Wed, Nov 15, 2023 at 08:48:00PM +0300, Arseny Maslennikov wrote:
> часть её протокола взаимодействия с кем-то, то лучше завести отдельную,
> _kdesu какое-нибудь.

У нас же правило о том, что имена системных усеров и групп, добавляемых
пакетами, должны начинаться с _, утверждено как обязательное, надеюсь?

Так себе и представляю живого пользователя-анимешника с никнеймом K-desu. :]

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [devel] UserGroupPolicy ?

[Anton Farygin]

On 15.11.2023 20:52, Arseny Maslennikov wrote:
> On Wed, Nov 15, 2023 at 08:48:00PM +0300, Arseny Maslennikov wrote:
>> часть её протокола взаимодействия с кем-то, то лучше завести отдельную,
>> _kdesu какое-нибудь.
> У нас же правило о том, что имена системных усеров и групп, добавляемых
> пакетами, должны начинаться с _, утверждено как обязательное, надеюсь?
>
> Так себе и представляю живого пользователя-анимешника с никнеймом K-desu. :]

Не видел такого правила.

Это, кстати, было бы отлично привести в порядок.

Есть ещё одна проблема - иногда так случается, что системные сервисы на 
разных узлах должны работать под одним UID/GID

Сейчас у нас нет внятного механизма заведения таких системных пользователей.

А у пакета setup очень консервативные ментейнеры.

Было бы неплохо придумать какую-то схему по выделению/резервированию 
UID/GID для системных служб.

Re: [devel] UserGroupPolicy ?

[Arseny Maslennikov]

[-- Attachment #1: Type: text/plain, Size: 3420 bytes --]

On Thu, Nov 16, 2023 at 08:39:13AM +0300, Anton Farygin wrote:
> On 15.11.2023 20:52, Arseny Maslennikov wrote:
> > On Wed, Nov 15, 2023 at 08:48:00PM +0300, Arseny Maslennikov wrote:
> > > часть её протокола взаимодействия с кем-то, то лучше завести отдельную,
> > > _kdesu какое-нибудь.
> > У нас же правило о том, что имена системных усеров и групп, добавляемых
> > пакетами, должны начинаться с _, утверждено как обязательное, надеюсь?
> > 
> > Так себе и представляю живого пользователя-анимешника с никнеймом K-desu. :]
> 
> Не видел такого правила.
> 
> Это, кстати, было бы отлично привести в порядок.

И заодно разобраться с подразумеваемым смыслом всяких волшебных групп вроде wheel.
Ничего, впрочем, не мешает сначала утвердить nobody, а далее, если появится
пропозал, включить содержимое NobodySubjectPolicy целиком или частично туда.

> Есть ещё одна проблема - иногда так случается, что системные сервисы на
> разных узлах должны работать под одним UID/GID

Это чтобы потакать криворукому софту, или ради общих R/W ФС на кластер?

> Сейчас у нас нет внятного механизма заведения таких системных пользователей.
> 
> А у пакета setup очень консервативные ментейнеры.
> 
> Было бы неплохо придумать какую-то схему по выделению/резервированию UID/GID
> для системных служб.

Я не уверен, что это реально нужно и стоит делать в репозитории.

Наверное, будет удобно и достаточно стащить у системдоидов программу
sysusers[1], превратив её в самостоятельную.

Далее — завести пакет static-ugids-setup, где вести реестр таких уидов в
виде отдельных файликов-записей. Внутри одного пакета будет легче
следить за непересечениями, чем между разными пакетами. Пакет без явного
мейнтейнера (@everybody), но с проверкой.
Но тогда непонятно, из какого диапазона можно безопасно выделять уиды
так, чтобы они не были заняты в существующих системах, и хватит ли этих
уидов всем таким капризным службам в репозитории.
Директива DynamicUser= в systemd себе прихватила некоторый отрезок после
[UG]ID_MAX-настройки в /etc/login.defs.

[1] man 5 sysusers.d

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [devel] UserGroupPolicy ?

[Anton Farygin]

On 20.11.2023 11:49, Arseny Maslennikov wrote:
> On Thu, Nov 16, 2023 at 08:39:13AM +0300, Anton Farygin wrote:
>> On 15.11.2023 20:52, Arseny Maslennikov wrote:
>>> On Wed, Nov 15, 2023 at 08:48:00PM +0300, Arseny Maslennikov wrote:
>>>> часть её протокола взаимодействия с кем-то, то лучше завести отдельную,
>>>> _kdesu какое-нибудь.
>>> У нас же правило о том, что имена системных усеров и групп, добавляемых
>>> пакетами, должны начинаться с _, утверждено как обязательное, надеюсь?
>>>
>>> Так себе и представляю живого пользователя-анимешника с никнеймом K-desu. :]
>> Не видел такого правила.
>>
>> Это, кстати, было бы отлично привести в порядок.
> И заодно разобраться с подразумеваемым смыслом всяких волшебных групп вроде wheel.
> Ничего, впрочем, не мешает сначала утвердить nobody, а далее, если появится
> пропозал, включить содержимое NobodySubjectPolicy целиком или частично туда.
Да, против Nobody ничего не имею.
>
>> Есть ещё одна проблема - иногда так случается, что системные сервисы на
>> разных узлах должны работать под одним UID/GID
> Это чтобы потакать криворукому софту, или ради общих R/W ФС на кластер?

Общие R/W ФС на кластер, сохранение/восстановление из бэкапа, 
копирование данных из одного сервера в другой через rsync.

Сценариев точно больше одного. Кривой софт тоже встречается, но гораздо 
реже.


>
>> Сейчас у нас нет внятного механизма заведения таких системных пользователей.
>>
>> А у пакета setup очень консервативные ментейнеры.
>>
>> Было бы неплохо придумать какую-то схему по выделению/резервированию UID/GID
>> для системных служб.
> Я не уверен, что это реально нужно и стоит делать в репозитории.
> Наверное, будет удобно и достаточно стащить у системдоидов программу
> sysusers[1], превратив её в самостоятельную.
>
> Далее — завести пакет static-ugids-setup, где вести реестр таких уидов в
> виде отдельных файликов-записей. Внутри одного пакета будет легче
> следить за непересечениями, чем между разными пакетами. Пакет без явного
> мейнтейнера (@everybody), но с проверкой.
> Но тогда непонятно, из какого диапазона можно безопасно выделять уиды
> так, чтобы они не были заняты в существующих системах, и хватит ли этих
> уидов всем таким капризным службам в репозитории.
> Директива DynamicUser= в systemd себе прихватила некоторый отрезок после
> [UG]ID_MAX-настройки в /etc/login.defs.
>
> [1] man 5 sysusers.d

Да, вопросов возникает тоже много. Ответы на них надо прорабатывать, а 
sysusers выглядит интересной идеей для реализации политики управления 
системными пользователями.

Контроль за соблюдением в пакетах можно переложить на sisyphus_check, 
например.

Re: [devel] UserGroupPolicy ?

[Alexey Shabalin]

пн, 20 нояб. 2023 г. в 12:20, Anton Farygin <rider@basealt.ru>:
>
> On 20.11.2023 11:49, Arseny Maslennikov wrote:
> > On Thu, Nov 16, 2023 at 08:39:13AM +0300, Anton Farygin wrote:
> >> On 15.11.2023 20:52, Arseny Maslennikov wrote:
> >>> On Wed, Nov 15, 2023 at 08:48:00PM +0300, Arseny Maslennikov wrote:
> >>>> часть её протокола взаимодействия с кем-то, то лучше завести отдельную,
> >>>> _kdesu какое-нибудь.
> >>> У нас же правило о том, что имена системных усеров и групп, добавляемых
> >>> пакетами, должны начинаться с _, утверждено как обязательное, надеюсь?
> >>>
> >>> Так себе и представляю живого пользователя-анимешника с никнеймом K-desu. :]
> >> Не видел такого правила.
> >>
> >> Это, кстати, было бы отлично привести в порядок.
> > И заодно разобраться с подразумеваемым смыслом всяких волшебных групп вроде wheel.
> > Ничего, впрочем, не мешает сначала утвердить nobody, а далее, если появится
> > пропозал, включить содержимое NobodySubjectPolicy целиком или частично туда.
> Да, против Nobody ничего не имею.
> >
> >> Есть ещё одна проблема - иногда так случается, что системные сервисы на
> >> разных узлах должны работать под одним UID/GID
> > Это чтобы потакать криворукому софту, или ради общих R/W ФС на кластер?
>
> Общие R/W ФС на кластер, сохранение/восстановление из бэкапа,
> копирование данных из одного сервера в другой через rsync.
>
> Сценариев точно больше одного. Кривой софт тоже встречается, но гораздо
> реже.
>
>
> >
> >> Сейчас у нас нет внятного механизма заведения таких системных пользователей.
> >>
> >> А у пакета setup очень консервативные ментейнеры.

На самом деле, консервативный мантейнер (ldv@) согласился со мной, что
бывают ситуации, где необходим статический UID/GUI. Или сделал вид что
согласился :)
Если будет предложен нормальный вариант, я думаю они будут не против.

> >>
> >> Было бы неплохо придумать какую-то схему по выделению/резервированию UID/GID
> >> для системных служб.
> > Я не уверен, что это реально нужно и стоит делать в репозитории.

Можно быть сколько угодно уверенным или нет. Такая необходимость
просто существует.
Еще раз, не всем и не везде это нужно, но это нужно.
И уже сейчас в репо есть пакеты, где useradd/groupadd вызываются с
указанием UID/GUID.
Нужно легитимизировать такую практику и придумать правила.

> > Наверное, будет удобно и достаточно стащить у системдоидов программу
> > sysusers[1], превратив её в самостоятельную.
> >
> > Далее — завести пакет static-ugids-setup, где вести реестр таких уидов в
> > виде отдельных файликов-записей. Внутри одного пакета будет легче
> > следить за непересечениями, чем между разными пакетами. Пакет без явного
> > мейнтейнера (@everybody), но с проверкой.
> > Но тогда непонятно, из какого диапазона можно безопасно выделять уиды
> > так, чтобы они не были заняты в существующих системах, и хватит ли этих
> > уидов всем таким капризным службам в репозитории.
> > Директива DynamicUser= в systemd себе прихватила некоторый отрезок после
> > [UG]ID_MAX-настройки в /etc/login.defs.

61184…65519 - UIDs for dynamic users
Они не подпадают под категорию статических системных пользователей.
Давайте не будем их тут рассматривать.

Сейчас у нас системные пользователи до 1000, раньше были до 500.
useradd/groupadd начинает выдавать системным пользователям uid/gui с
конца в сторону уменьшения (сейчас с 999, раньше с 499).
Можно предположить, что на старых системах диапазон от 400-499 занят и
500-599 тоже, на новых 900-999 занят.
Думаю, для статических uid/gui диапазон 100-400 или 600-900
относительно безопасен. Конечно не на все 100%.


> >
> > [1] man 5 sysusers.d
>
> Да, вопросов возникает тоже много. Ответы на них надо прорабатывать, а
> sysusers выглядит интересной идеей для реализации политики управления
> системными пользователями.
>
> Контроль за соблюдением в пакетах можно переложить на sisyphus_check,
> например.

Давайте прикинем варианты учета и правила создания таких статических UID/GID.
- страничка на wiki с таблицей статических UID/GID. Этот вариант можно
сразу отвергнуть. Единоразово страницу сделать можно, но потом без
автоматического обновления она быстро перестанет быть актуально.
- пакет static-ugids-setup. пользователю приедет куча ненужных
системных пользователей и групп, еще и с домашними директориями.
- у меня еще была идея провайдить в rpm что-то типа sysusers(uid) =
300 и sysusers(gid) = 300 для системных пользователей, создаваемых в
%pre. Тогда сборочница сама отследит одинаковые провайды и не
пропустит пакет.
- у нас нет макросов для useradd и groupadd, сейчас что только не
пишут в %pre. Для унификации создания системных пользователей стоит
задействовать sysusers (отработает и в systemd, и в sysv). Если в этих
файлах прописан статический UID/GID то можно автоматически выставлять
Provides: sysusers(uid) = $UID и т.п.

-- 
Alexey Shabalin

[devel] UID/GID pinning for packaged services

[Arseny Maslennikov]

[-- Attachment #1: Type: text/plain, Size: 9174 bytes --]

On Mon, Nov 20, 2023 at 03:25:54PM +0300, Alexey Shabalin wrote:
> пн, 20 нояб. 2023 г. в 12:20, Anton Farygin <rider@basealt.ru>:
> > On 20.11.2023 11:49, Arseny Maslennikov wrote:
> > > On Thu, Nov 16, 2023 at 08:39:13AM +0300, Anton Farygin wrote:
> > >> Есть ещё одна проблема - иногда так случается, что системные сервисы на
> > >> разных узлах должны работать под одним UID/GID
> > > Это чтобы потакать криворукому софту, или ради общих R/W ФС на кластер?
> >
> > Общие R/W ФС на кластер, сохранение/восстановление из бэкапа,
> > копирование данных из одного сервера в другой через rsync.
> >
> > Сценариев точно больше одного. Кривой софт тоже встречается, но гораздо
> > реже.

Все описанные сценарии затрагивают конкретные деплойменты (на местах у
людей), которые никак не касаются мн-ва остальных пользователей.

А ещё все описанные сценарии касаются общих ресурсов, где хранятся эти
uid/gid в качестве метаданных, но тут не буду настаивать.

Иными словами, всё ещё не требуется синхронизировать все инсталляции альта в
мире, фиксировать эти числа в _глобальном_ реестре. Можно искать решение
для конкретных инсталляций: администратор на этапе установки доводит до
установщика пожелание: "разверните мне систему и пакеты так, чтобы
уид/гид у сервиса X был ровно N". Т. е. поддержка в альтератор-headless
(или как у нас неинтерактивный инсталлятор называется?), может быть, даже
в GUI инсталлятора.

> > >
> > >> Сейчас у нас нет внятного механизма заведения таких системных пользователей.
> > >>
> > >> А у пакета setup очень консервативные ментейнеры.
> 
> На самом деле, консервативный мантейнер (ldv@) согласился со мной, что
> бывают ситуации, где необходим статический UID/GUI. Или сделал вид что

Бывают. Все они, скорее всего, сводятся к тому, что uid/gid используется
до того, как появляется доступ к nsswitch, а то и раньше, чем появляется
/etc (то есть, в initramfs), и компоненты, ими пользующиеся, начинают
это делать на столь раннем этапе работы (старта) системы.
А если не все — буду рад увидеть контрпримеры.
 
> > >> Было бы неплохо придумать какую-то схему по выделению/резервированию UID/GID
> > >> для системных служб.
> > > Я не уверен, что это реально нужно и стоит делать в репозитории.

Ключевыми у меня здесь являются слова "в репозитории". :)
Я не возражаю против поддержки гвоздями прибитых ugid как таковой,
просто решение о том, какое должно быть число, совсем не обязательно
принимать рано, в репозитории; его можно отложить, например, до работы
установщика.
Я не уверен, что реестр должен быть общим для всех установок альта в
в мире.

> Можно быть сколько угодно уверенным или нет. Такая необходимость
> просто существует.
> Еще раз, не всем и не везде это нужно, но это нужно.
> И уже сейчас в репо есть пакеты, где useradd/groupadd вызываются с
> указанием UID/GUID.
> Нужно легитимизировать такую практику и придумать правила.
> 
> > > Наверное, будет удобно и достаточно стащить у системдоидов программу
> > > sysusers[1], превратив её в самостоятельную.
> > >
> > > Далее — завести пакет static-ugids-setup, где вести реестр таких уидов в
> > > виде отдельных файликов-записей. Внутри одного пакета будет легче
> > > следить за непересечениями, чем между разными пакетами. Пакет без явного
> > > мейнтейнера (@everybody), но с проверкой.
> > > Но тогда непонятно, из какого диапазона можно безопасно выделять уиды
> > > так, чтобы они не были заняты в существующих системах, и хватит ли этих
> > > уидов всем таким капризным службам в репозитории.
> > > Директива DynamicUser= в systemd себе прихватила некоторый отрезок после
> > > [UG]ID_MAX-настройки в /etc/login.defs.
> 
> 61184…65519 - UIDs for dynamic users
> Они не подпадают под категорию статических системных пользователей.
> Давайте не будем их тут рассматривать.
> 
> Сейчас у нас системные пользователи до 1000, раньше были до 500.
> useradd/groupadd начинает выдавать системным пользователям uid/gui с
> конца в сторону уменьшения (сейчас с 999, раньше с 499).
> Можно предположить, что на старых системах диапазон от 400-499 занят и
> 500-599 тоже, на новых 900-999 занят.
> Думаю, для статических uid/gui диапазон 100-400 или 600-900
> относительно безопасен. Конечно не на все 100%.
> 
> 
> > >
> > > [1] man 5 sysusers.d
> >
> > Да, вопросов возникает тоже много. Ответы на них надо прорабатывать, а
> > sysusers выглядит интересной идеей для реализации политики управления
> > системными пользователями.
> >
> > Контроль за соблюдением в пакетах можно переложить на sisyphus_check,
> > например.
> 
> Давайте прикинем варианты учета и правила создания таких статических UID/GID.
> - страничка на wiki с таблицей статических UID/GID. Этот вариант можно
> сразу отвергнуть. Единоразово страницу сделать можно, но потом без
> автоматического обновления она быстро перестанет быть актуально.
> - пакет static-ugids-setup. пользователю приедет куча ненужных
> системных пользователей и групп, еще и с домашними директориями.
> - у меня еще была идея провайдить в rpm что-то типа sysusers(uid) =
> 300 и sysusers(gid) = 300 для системных пользователей, создаваемых в
> %pre. Тогда сборочница сама отследит одинаковые провайды и не
> пропустит пакет.
> - у нас нет макросов для useradd и groupadd, сейчас что только не
> пишут в %pre. Для унификации создания системных пользователей стоит
> задействовать sysusers (отработает и в systemd, и в sysv). Если в этих
> файлах прописан статический UID/GID то можно автоматически выставлять
> Provides: sysusers(uid) = $UID и т.п.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [devel] UID/GID pinning for packaged services

[Denis Medvedev]

On Mon, 20 Nov 2023 17:15:21 +0300
Arseny Maslennikov <arseny@altlinux.org> wrote:

> On Mon, Nov 20, 2023 at 03:25:54PM +0300, Alexey Shabalin wrote:
> > пн, 20 нояб. 2023 г. в 12:20, Anton Farygin <rider@basealt.ru>:
> > > On 20.11.2023 11:49, Arseny Maslennikov wrote:
> > > > On Thu, Nov 16, 2023 at 08:39:13AM +0300, Anton Farygin wrote:
> > > >> Есть ещё одна проблема - иногда так случается, что системные
> > > >> сервисы на разных узлах должны работать под одним UID/GID
> > > > Это чтобы потакать криворукому софту, или ради общих R/W ФС на
> > > > кластер?
> > >
> > > Общие R/W ФС на кластер, сохранение/восстановление из бэкапа,
> > > копирование данных из одного сервера в другой через rsync.
> > >
> > > Сценариев точно больше одного. Кривой софт тоже встречается, но
> > > гораздо реже.
> 
> Все описанные сценарии затрагивают конкретные деплойменты (на местах у
> людей), которые никак не касаются мн-ва остальных пользователей.
> 
> А ещё все описанные сценарии касаются общих ресурсов, где хранятся эти
> uid/gid в качестве метаданных, но тут не буду настаивать.
> 
> Иными словами, всё ещё не требуется синхронизировать все инсталляции
> альта в мире, фиксировать эти числа в _глобальном_ реестре. Можно
> искать решение для конкретных инсталляций: администратор на этапе
> установки доводит до установщика пожелание: "разверните мне систему и
> пакеты так, чтобы уид/гид у сервиса X был ровно N". Т. е. поддержка в
> альтератор-headless (или как у нас неинтерактивный инсталлятор
> называется?), может быть, даже в GUI инсталлятора.
> 
> > > >
> > > >> Сейчас у нас нет внятного механизма заведения таких системных
> > > >> пользователей.
> > > >>
> > > >> А у пакета setup очень консервативные ментейнеры.
> > 
> > На самом деле, консервативный мантейнер (ldv@) согласился со мной,
> > что бывают ситуации, где необходим статический UID/GUI. Или сделал
> > вид что
> 
> Бывают. Все они, скорее всего, сводятся к тому, что uid/gid
> используется до того, как появляется доступ к nsswitch, а то и
> раньше, чем появляется /etc (то есть, в initramfs), и компоненты, ими
> пользующиеся, начинают это делать на столь раннем этапе работы
> (старта) системы. А если не все — буду рад увидеть контрпримеры.
в pam можно указывать только числовые значения для = или >=
В частности, для selinux приходилось резервировать числовое значение
"90" для выделенного администратора которого надо было прописывать в
pam.
>  
> > > >> Было бы неплохо придумать какую-то схему по
> > > >> выделению/резервированию UID/GID для системных служб.
> > > > Я не уверен, что это реально нужно и стоит делать в репозитории.
> 
> Ключевыми у меня здесь являются слова "в репозитории". :)
> Я не возражаю против поддержки гвоздями прибитых ugid как таковой,
> просто решение о том, какое должно быть число, совсем не обязательно
> принимать рано, в репозитории; его можно отложить, например, до работы
> установщика.
> Я не уверен, что реестр должен быть общим для всех установок альта в
> в мире.
> 
> > Можно быть сколько угодно уверенным или нет. Такая необходимость
> > просто существует.
> > Еще раз, не всем и не везде это нужно, но это нужно.
> > И уже сейчас в репо есть пакеты, где useradd/groupadd вызываются с
> > указанием UID/GUID.
> > Нужно легитимизировать такую практику и придумать правила.
> > 
> > > > Наверное, будет удобно и достаточно стащить у системдоидов
> > > > программу sysusers[1], превратив её в самостоятельную.
> > > >
> > > > Далее — завести пакет static-ugids-setup, где вести реестр
> > > > таких уидов в виде отдельных файликов-записей. Внутри одного
> > > > пакета будет легче следить за непересечениями, чем между
> > > > разными пакетами. Пакет без явного мейнтейнера (@everybody), но
> > > > с проверкой. Но тогда непонятно, из какого диапазона можно
> > > > безопасно выделять уиды так, чтобы они не были заняты в
> > > > существующих системах, и хватит ли этих уидов всем таким
> > > > капризным службам в репозитории. Директива DynamicUser= в
> > > > systemd себе прихватила некоторый отрезок после
> > > > [UG]ID_MAX-настройки в /etc/login.defs.
> > 
> > 61184…65519 - UIDs for dynamic users
> > Они не подпадают под категорию статических системных пользователей.
> > Давайте не будем их тут рассматривать.
> > 
> > Сейчас у нас системные пользователи до 1000, раньше были до 500.
> > useradd/groupadd начинает выдавать системным пользователям uid/gui с
> > конца в сторону уменьшения (сейчас с 999, раньше с 499).
> > Можно предположить, что на старых системах диапазон от 400-499
> > занят и 500-599 тоже, на новых 900-999 занят.
> > Думаю, для статических uid/gui диапазон 100-400 или 600-900
> > относительно безопасен. Конечно не на все 100%.
> > 
> > 
> > > >
> > > > [1] man 5 sysusers.d
> > >
> > > Да, вопросов возникает тоже много. Ответы на них надо
> > > прорабатывать, а sysusers выглядит интересной идеей для
> > > реализации политики управления системными пользователями.
> > >
> > > Контроль за соблюдением в пакетах можно переложить на
> > > sisyphus_check, например.
> > 
> > Давайте прикинем варианты учета и правила создания таких
> > статических UID/GID.
> > - страничка на wiki с таблицей статических UID/GID. Этот вариант
> > можно сразу отвергнуть. Единоразово страницу сделать можно, но
> > потом без автоматического обновления она быстро перестанет быть
> > актуально.
> > - пакет static-ugids-setup. пользователю приедет куча ненужных
> > системных пользователей и групп, еще и с домашними директориями.
> > - у меня еще была идея провайдить в rpm что-то типа sysusers(uid) =
> > 300 и sysusers(gid) = 300 для системных пользователей, создаваемых в
> > %pre. Тогда сборочница сама отследит одинаковые провайды и не
> > пропустит пакет.
> > - у нас нет макросов для useradd и groupadd, сейчас что только не
> > пишут в %pre. Для унификации создания системных пользователей стоит
> > задействовать sysusers (отработает и в systemd, и в sysv). Если в
> > этих файлах прописан статический UID/GID то можно автоматически
> > выставлять Provides: sysusers(uid) = $UID и т.п.

Re: [devel] UID/GID pinning for packaged services

[Dmitry V. Levin]

On Mon, Nov 20, 2023 at 05:36:30PM +0300, Denis Medvedev wrote:
[...]
> в pam можно указывать только числовые значения для = или >=

В pam_succeed_if чего только нет, например, user ingroup.
Ну и, конечно, PAM можно и пропатчить, если что.


-- 
ldv

Re: [devel] NobodySubjectPolicy draft

[Sergey V Turchin]

On Wednesday, 15 November 2023 20:52:45 MSK Arseny Maslennikov wrote:
> On Wed, Nov 15, 2023 at 08:48:00PM +0300, Arseny Maslennikov wrote:
> > часть её протокола взаимодействия с кем-то, то лучше завести отдельную,
> > _kdesu какое-нибудь.
> 
> У нас же правило о том, что имена системных усеров и групп, добавляемых
> пакетами, должны начинаться с _, утверждено как обязательное, надеюсь?
Нет, кончечо. Иначе sddm будет патчить тот, кто утвердит это правило.

> Так себе и представляю живого пользователя-анимешника с никнеймом K-desu. :]


-- 
Regards, Sergey.

Re: [devel] NobodySubjectPolicy draft

[Anton Farygin]

On 16.11.2023 09:55, Sergey V Turchin wrote:
> On Wednesday, 15 November 2023 20:52:45 MSK Arseny Maslennikov wrote:
>> On Wed, Nov 15, 2023 at 08:48:00PM +0300, Arseny Maslennikov wrote:
>>> часть её протокола взаимодействия с кем-то, то лучше завести отдельную,
>>> _kdesu какое-нибудь.
>> У нас же правило о том, что имена системных усеров и групп, добавляемых
>> пакетами, должны начинаться с _, утверждено как обязательное, надеюсь?
> Нет, кончечо. Иначе sddm будет патчить тот, кто утвердит это правило.

А зачем его патчить ?

Re: [devel] NobodySubjectPolicy draft

[Sergey V Turchin]

On Thursday, 16 November 2023 10:57:38 MSK Anton Farygin wrote:
> On 16.11.2023 09:55, Sergey V Turchin wrote:
> > On Wednesday, 15 November 2023 20:52:45 MSK Arseny Maslennikov wrote:
> >> On Wed, Nov 15, 2023 at 08:48:00PM +0300, Arseny Maslennikov wrote:
> >>> часть её протокола взаимодействия с кем-то, то лучше завести отдельную,
> >>> _kdesu какое-нибудь.
> >> 
> >> У нас же правило о том, что имена системных усеров и групп, добавляемых
> >> пакетами, должны начинаться с _, утверждено как обязательное, надеюсь?
> > 
> > Нет, кончечо. Иначе sddm будет патчить тот, кто утвердит это правило.
> 
> А зачем его патчить ?
По другому с _ не будет.

-- 
Regards, Sergey.

Re: [devel] NobodySubjectPolicy draft

[Anton Farygin]

On 16.11.2023 11:03, Sergey V Turchin wrote:
> On Thursday, 16 November 2023 10:57:38 MSK Anton Farygin wrote:
>> On 16.11.2023 09:55, Sergey V Turchin wrote:
>>> On Wednesday, 15 November 2023 20:52:45 MSK Arseny Maslennikov wrote:
>>>> On Wed, Nov 15, 2023 at 08:48:00PM +0300, Arseny Maslennikov wrote:
>>>>> часть её протокола взаимодействия с кем-то, то лучше завести отдельную,
>>>>> _kdesu какое-нибудь.
>>>> У нас же правило о том, что имена системных усеров и групп, добавляемых
>>>> пакетами, должны начинаться с _, утверждено как обязательное, надеюсь?
>>> Нет, кончечо. Иначе sddm будет патчить тот, кто утвердит это правило.
>> А зачем его патчить ?
> По другому с _ не будет.
>
Он же уже сейчас отсекает системных пользователей по другому критерию 
(по второму)

Re: [devel] NobodySubjectPolicy draft

[Sergey V Turchin]

On Thursday, 16 November 2023 11:33:08 MSK Anton Farygin wrote:
> On 16.11.2023 11:03, Sergey V Turchin wrote:
> > On Thursday, 16 November 2023 10:57:38 MSK Anton Farygin wrote:
> >> On 16.11.2023 09:55, Sergey V Turchin wrote:
> >>> On Wednesday, 15 November 2023 20:52:45 MSK Arseny Maslennikov wrote:
> >>>> On Wed, Nov 15, 2023 at 08:48:00PM +0300, Arseny Maslennikov wrote:
> >>>>> часть её протокола взаимодействия с кем-то, то лучше завести
> >>>>> отдельную,
> >>>>> _kdesu какое-нибудь.
> >>>> 
> >>>> У нас же правило о том, что имена системных усеров и групп, добавляемых
> >>>> пакетами, должны начинаться с _, утверждено как обязательное, надеюсь?
> >>> 
> >>> Нет, кончечо. Иначе sddm будет патчить тот, кто утвердит это правило.
> >> 
> >> А зачем его патчить ?
> > 
> > По другому с _ не будет.
> Он же уже сейчас отсекает системных пользователей по другому критерию
> (по второму)
А начнёт отсекать мантейнеров, кто не хочет искать во всем исходниками буквы 
"sddm". ;-)

-- 
Regards, Sergey.

Re: [devel] NobodySubjectPolicy draft

[Anton Farygin]

On 16.11.2023 11:41, Sergey V Turchin wrote:
> On Thursday, 16 November 2023 11:33:08 MSK Anton Farygin wrote:
>> On 16.11.2023 11:03, Sergey V Turchin wrote:
>>> On Thursday, 16 November 2023 10:57:38 MSK Anton Farygin wrote:
>>>> On 16.11.2023 09:55, Sergey V Turchin wrote:
>>>>> On Wednesday, 15 November 2023 20:52:45 MSK Arseny Maslennikov wrote:
>>>>>> On Wed, Nov 15, 2023 at 08:48:00PM +0300, Arseny Maslennikov wrote:
>>>>>>> часть её протокола взаимодействия с кем-то, то лучше завести
>>>>>>> отдельную,
>>>>>>> _kdesu какое-нибудь.
>>>>>> У нас же правило о том, что имена системных усеров и групп, добавляемых
>>>>>> пакетами, должны начинаться с _, утверждено как обязательное, надеюсь?
>>>>> Нет, кончечо. Иначе sddm будет патчить тот, кто утвердит это правило.
>>>> А зачем его патчить ?
>>> По другому с _ не будет.
>> Он же уже сейчас отсекает системных пользователей по другому критерию
>> (по второму)
> А начнёт отсекать мантейнеров, кто не хочет искать во всем исходниками буквы
> "sddm". ;-)
>
Так это же прекрасно.

На самом деле политику с системными пользователями надо распространять 
на другие проекты через апстримы - я вообще не понимаю какое будет 
поведение у системы, если например будет доменный пользователь с именем sddm

Re: [devel] NobodySubjectPolicy draft

[Sergey V Turchin]

On Thursday, 16 November 2023 11:52:09 MSK Anton Farygin wrote:
> On 16.11.2023 11:41, Sergey V Turchin wrote:
> > On Thursday, 16 November 2023 11:33:08 MSK Anton Farygin wrote:
> >> On 16.11.2023 11:03, Sergey V Turchin wrote:
> >>> On Thursday, 16 November 2023 10:57:38 MSK Anton Farygin wrote:
> >>>> On 16.11.2023 09:55, Sergey V Turchin wrote:
> >>>>> On Wednesday, 15 November 2023 20:52:45 MSK Arseny Maslennikov wrote:
> >>>>>> On Wed, Nov 15, 2023 at 08:48:00PM +0300, Arseny Maslennikov wrote:
> >>>>>>> часть её протокола взаимодействия с кем-то, то лучше завести
> >>>>>>> отдельную,
> >>>>>>> _kdesu какое-нибудь.
> >>>>>> 
> >>>>>> У нас же правило о том, что имена системных усеров и групп,
> >>>>>> добавляемых
> >>>>>> пакетами, должны начинаться с _, утверждено как обязательное,
> >>>>>> надеюсь?
> >>>>> 
> >>>>> Нет, кончечо. Иначе sddm будет патчить тот, кто утвердит это правило.
> >>>> 
> >>>> А зачем его патчить ?
> >>> 
> >>> По другому с _ не будет.
> >> 
> >> Он же уже сейчас отсекает системных пользователей по другому критерию
> >> (по второму)
> > 
> > А начнёт отсекать мантейнеров, кто не хочет искать во всем исходниками
> > буквы "sddm". ;-)
> 
> Так это же прекрасно.
> 
> На самом деле политику с системными пользователями надо распространять
> на другие проекты через апстримы 
Полагаю, это лучше делать до геморроя мантейнерам.

> - я вообще не понимаю какое будет
> поведение у системы, если например будет доменный пользователь с именем sddm


-- 
Regards, Sergey.

Re: [devel] NobodySubjectPolicy draft

[Sergey V Turchin]

On Wednesday, 15 November 2023 20:47:56 MSK Arseny Maslennikov wrote:
> On Wed, Nov 15, 2023 at 04:42:21PM +0300, Sergey V Turchin wrote:
> > On Wednesday, 15 November 2023 16:00:56 MSK you wrote:
> > 
> > [...]
> > 
> > > Вот этот пакет зачем-то пытается ставить в систему исполнимый бинарник с
> > > setgid nobody: kf5-kdesu	zerg
> > > Забавно, что этот бинарник после установки в хешерницу всё же
> > > оказывается
> > > 2711/root/root.
> > 
> > Там для этого файла хоть 0000, не важно.
> > 
> > На что сменить? Сделать пользователя kde_nobody?
> 
> С точки зрения сабжа — лишь бы не nobody и, если можно, лучше не 99.
> Я не пользователь KDE и не знаком с особенностями работы kdesu, но если
> можно хоть 0000, то можно и root:root оставить.
В той системе, которая в hasher, пофиг, будет ли вообще работать kdesu. Там su 
или sudo будет достаточно. ;-)

> А если эта программа реально должна повышать себе группу, например, это
> часть её протокола взаимодействия с кем-то,
С пользовательским родительским процессом из-под привелегированного.

> то лучше завести отдельную, _kdesu какое-нибудь.
Ок.

-- 
Regards, Sergey.

Re: [devel] NobodySubjectPolicy draft

[Sergey V Turchin]

On Wednesday, 15 November 2023 16:00:56 MSK Arseny Maslennikov wrote:

[...]
> - Запретить установку файловых объектов под nobody с пакетами;
У нас теперь есть 500 дополнительных UID для новых системных пользователей. 
Надеюсь, хватит. ;-)

[...]

-- 
Regards, Sergey.

Re: [devel] NobodySubjectPolicy draft

[Arseny Maslennikov]

[-- Attachment #1: Type: text/plain, Size: 656 bytes --]

On Mon, Nov 20, 2023 at 11:23:38AM +0300, Sergey V Turchin wrote:
> On Wednesday, 15 November 2023 16:00:56 MSK Arseny Maslennikov wrote:
> 
> [...]
> > - Запретить установку файловых объектов под nobody с пакетами;
> У нас теперь есть 500 дополнительных UID для новых системных пользователей. 
> Надеюсь, хватит. ;-)

Ага.

Не хватать начнёт, если достаточно большому кол-ву сервисов в
репозитории выдавать заранее известные числа.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [devel] NobodySubjectPolicy draft

[Arseny Maslennikov]

[-- Attachment #1: Type: text/plain, Size: 2362 bytes --]

On Wed, Nov 15, 2023 at 04:00:56PM +0300, Arseny Maslennikov wrote:
> === Предложение ===
> 
> Вношу следующее предложение:
> - Сменить пользователю и группе nobody численный идентификатор с 99 на
>   65534. Для обозначения 99-го оставить другое имя, например, _nobody99;
> - Передать /var/nobody этому самому _nobody99;

В частности, планирую записать в надлежащие места следующие строчки:

- В пакете setup, файл passwd.master и аналогично group.master:
  nobody:*:65534:65534:Linux Kernel overflowuid:/dev/null:/dev/null
  _nobody99:*:99:99:Nobody:/var/nobody:/dev/null

- В пакете filesystem в спеке:
  %attr(0750,root,_nobody99) %dir /var/nobody

> Для пакетов в Sisyphus:
> - Запретить установку файловых объектов под nobody с пакетами;

А также:
- В пакете sisyphus_check дополнить проверку 140-check-perms;

> - Рекомендовать мейнтейнерам не допускать, чтобы собираемые ими
>   системные службы исполняли код под nobody;

Скорее всего, нужна автопроверка устанавливаемых systemd-юнитов, чтобы
в сервисах не было директив User= и Group= со значением nobody, а также
чтобы список в SupplementaryGroups= не содержал значение nobody.

Как проверять инит-скрипты, пусть лучше подскажут пользователи этой
rc-системы.

> - Рекомендовать администраторам не запускать процессы под юзером и группой
>   nobody.

Если не возникнет возражений, составлю сборочное задание (это будет
330460, но сейчас там предыдущий вариант патча на setup).

Какие ещё пакеты, кроме systemd, запоминают UID и GID для nobody во время сборки?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [devel] NobodySubjectPolicy draft

[Arseny Maslennikov]

[-- Attachment #1: Type: text/plain, Size: 1001 bytes --]

On Wed, Nov 15, 2023 at 04:00:56PM +0300, Arseny Maslennikov wrote:
> Hi!
> 
> (Видимо, потребуется проходить процедуру PolicyPolicy, но писать статью
> на вики и воевать с разметкой MediaWiki сейчас некогда, так что начнём
> обсуждение этим письмом, а страницу по его тексту составим позже)

Страница составлена:
https://altlinux.org/NobodySubjectPolicy

Судя по policy policy, обсуждение должно длиться ещё неделю.

Соответствующие правки, которые будут внесены в системные файлы и
автоматические проверки, можно посмотреть здесь:
https://packages.altlinux.org/tasks/330460
В этом задании нужно будет пересобрать как минимум systemd.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [devel] NobodySubjectPolicy draft

[Arseny Maslennikov]

[-- Attachment #1: Type: text/plain, Size: 1034 bytes --]

On Wed, Nov 15, 2023 at 04:00:56PM +0300, Arseny Maslennikov wrote:
> Hi!
> 
> (Видимо, потребуется проходить процедуру PolicyPolicy, но писать статью
> на вики и воевать с разметкой MediaWiki сейчас некогда, так что начнём
> обсуждение этим письмом, а страницу по его тексту составим позже)

По этой процедуре:
> Если за две недели не находится существенных технических возражений к
> опубликованному черновику (мера существенности возражений определяется
> арбитром), то черновик считается принятым.
Так что, видимо, надо переводить черновик в статус принятого.

О мерах воплощения будет отдельное письмо.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]