* [devel] NobodySubjectPolicy draft @ 2023-11-15 13:00 Arseny Maslennikov 2023-11-15 13:42 ` Sergey V Turchin ` (4 more replies) 0 siblings, 5 replies; 24+ messages in thread From: Arseny Maslennikov @ 2023-11-15 13:00 UTC (permalink / raw) To: devel [-- 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 --] ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [devel] NobodySubjectPolicy draft 2023-11-15 13:00 [devel] NobodySubjectPolicy draft Arseny Maslennikov @ 2023-11-15 13:42 ` Sergey V Turchin 2023-11-15 17:47 ` Arseny Maslennikov 2023-11-20 8:23 ` Sergey V Turchin ` (3 subsequent siblings) 4 siblings, 1 reply; 24+ messages in thread From: Sergey V Turchin @ 2023-11-15 13:42 UTC (permalink / raw) To: devel 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. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [devel] NobodySubjectPolicy draft 2023-11-15 13:42 ` Sergey V Turchin @ 2023-11-15 17:47 ` Arseny Maslennikov 2023-11-15 17:52 ` Arseny Maslennikov 2023-11-16 7:02 ` Sergey V Turchin 0 siblings, 2 replies; 24+ messages in thread From: Arseny Maslennikov @ 2023-11-15 17:47 UTC (permalink / raw) To: ALT Linux Team development discussions [-- 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 --] ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [devel] NobodySubjectPolicy draft 2023-11-15 17:47 ` Arseny Maslennikov @ 2023-11-15 17:52 ` Arseny Maslennikov 2023-11-16 5:39 ` [devel] UserGroupPolicy ? Anton Farygin 2023-11-16 6:55 ` [devel] NobodySubjectPolicy draft Sergey V Turchin 2023-11-16 7:02 ` Sergey V Turchin 1 sibling, 2 replies; 24+ messages in thread From: Arseny Maslennikov @ 2023-11-15 17:52 UTC (permalink / raw) To: ALT Linux Team development discussions [-- 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 --] ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [devel] UserGroupPolicy ? 2023-11-15 17:52 ` Arseny Maslennikov @ 2023-11-16 5:39 ` Anton Farygin 2023-11-20 8:49 ` Arseny Maslennikov 2023-11-16 6:55 ` [devel] NobodySubjectPolicy draft Sergey V Turchin 1 sibling, 1 reply; 24+ messages in thread From: Anton Farygin @ 2023-11-16 5:39 UTC (permalink / raw) To: devel 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 для системных служб. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [devel] UserGroupPolicy ? 2023-11-16 5:39 ` [devel] UserGroupPolicy ? Anton Farygin @ 2023-11-20 8:49 ` Arseny Maslennikov 2023-11-20 9:20 ` Anton Farygin 0 siblings, 1 reply; 24+ messages in thread From: Arseny Maslennikov @ 2023-11-20 8:49 UTC (permalink / raw) To: ALT Linux Team development discussions [-- 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 --] ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [devel] UserGroupPolicy ? 2023-11-20 8:49 ` Arseny Maslennikov @ 2023-11-20 9:20 ` Anton Farygin 2023-11-20 12:25 ` Alexey Shabalin 0 siblings, 1 reply; 24+ messages in thread From: Anton Farygin @ 2023-11-20 9:20 UTC (permalink / raw) To: devel 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, например. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [devel] UserGroupPolicy ? 2023-11-20 9:20 ` Anton Farygin @ 2023-11-20 12:25 ` Alexey Shabalin 2023-11-20 14:15 ` [devel] UID/GID pinning for packaged services Arseny Maslennikov 0 siblings, 1 reply; 24+ messages in thread From: Alexey Shabalin @ 2023-11-20 12:25 UTC (permalink / raw) To: ALT Linux Team development discussions пн, 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* [devel] UID/GID pinning for packaged services 2023-11-20 12:25 ` Alexey Shabalin @ 2023-11-20 14:15 ` Arseny Maslennikov 2023-11-20 14:36 ` Denis Medvedev 0 siblings, 1 reply; 24+ messages in thread From: Arseny Maslennikov @ 2023-11-20 14:15 UTC (permalink / raw) To: ALT Linux Team development discussions [-- 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 --] ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [devel] UID/GID pinning for packaged services 2023-11-20 14:15 ` [devel] UID/GID pinning for packaged services Arseny Maslennikov @ 2023-11-20 14:36 ` Denis Medvedev 2023-11-20 15:48 ` Dmitry V. Levin 0 siblings, 1 reply; 24+ messages in thread From: Denis Medvedev @ 2023-11-20 14:36 UTC (permalink / raw) To: Arseny Maslennikov; +Cc: ALT Linux Team development discussions 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 и т.п. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [devel] UID/GID pinning for packaged services 2023-11-20 14:36 ` Denis Medvedev @ 2023-11-20 15:48 ` Dmitry V. Levin 0 siblings, 0 replies; 24+ messages in thread From: Dmitry V. Levin @ 2023-11-20 15:48 UTC (permalink / raw) To: devel On Mon, Nov 20, 2023 at 05:36:30PM +0300, Denis Medvedev wrote: [...] > в pam можно указывать только числовые значения для = или >= В pam_succeed_if чего только нет, например, user ingroup. Ну и, конечно, PAM можно и пропатчить, если что. -- ldv ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [devel] NobodySubjectPolicy draft 2023-11-15 17:52 ` Arseny Maslennikov 2023-11-16 5:39 ` [devel] UserGroupPolicy ? Anton Farygin @ 2023-11-16 6:55 ` Sergey V Turchin 2023-11-16 7:57 ` Anton Farygin 1 sibling, 1 reply; 24+ messages in thread From: Sergey V Turchin @ 2023-11-16 6:55 UTC (permalink / raw) To: ALT Linux Team development discussions 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. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [devel] NobodySubjectPolicy draft 2023-11-16 6:55 ` [devel] NobodySubjectPolicy draft Sergey V Turchin @ 2023-11-16 7:57 ` Anton Farygin 2023-11-16 8:03 ` Sergey V Turchin 0 siblings, 1 reply; 24+ messages in thread From: Anton Farygin @ 2023-11-16 7:57 UTC (permalink / raw) To: devel 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 будет патчить тот, кто утвердит это правило. А зачем его патчить ? ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [devel] NobodySubjectPolicy draft 2023-11-16 7:57 ` Anton Farygin @ 2023-11-16 8:03 ` Sergey V Turchin 2023-11-16 8:33 ` Anton Farygin 0 siblings, 1 reply; 24+ messages in thread From: Sergey V Turchin @ 2023-11-16 8:03 UTC (permalink / raw) To: ALT Linux Team development discussions 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. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [devel] NobodySubjectPolicy draft 2023-11-16 8:03 ` Sergey V Turchin @ 2023-11-16 8:33 ` Anton Farygin 2023-11-16 8:41 ` Sergey V Turchin 0 siblings, 1 reply; 24+ messages in thread From: Anton Farygin @ 2023-11-16 8:33 UTC (permalink / raw) To: devel 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 будет патчить тот, кто утвердит это правило. >> А зачем его патчить ? > По другому с _ не будет. > Он же уже сейчас отсекает системных пользователей по другому критерию (по второму) ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [devel] NobodySubjectPolicy draft 2023-11-16 8:33 ` Anton Farygin @ 2023-11-16 8:41 ` Sergey V Turchin 2023-11-16 8:52 ` Anton Farygin 0 siblings, 1 reply; 24+ messages in thread From: Sergey V Turchin @ 2023-11-16 8:41 UTC (permalink / raw) To: ALT Linux Team development discussions 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. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [devel] NobodySubjectPolicy draft 2023-11-16 8:41 ` Sergey V Turchin @ 2023-11-16 8:52 ` Anton Farygin 2023-11-16 8:58 ` Sergey V Turchin 0 siblings, 1 reply; 24+ messages in thread From: Anton Farygin @ 2023-11-16 8:52 UTC (permalink / raw) To: devel 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [devel] NobodySubjectPolicy draft 2023-11-16 8:52 ` Anton Farygin @ 2023-11-16 8:58 ` Sergey V Turchin 0 siblings, 0 replies; 24+ messages in thread From: Sergey V Turchin @ 2023-11-16 8:58 UTC (permalink / raw) To: ALT Linux Team development discussions 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. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [devel] NobodySubjectPolicy draft 2023-11-15 17:47 ` Arseny Maslennikov 2023-11-15 17:52 ` Arseny Maslennikov @ 2023-11-16 7:02 ` Sergey V Turchin 1 sibling, 0 replies; 24+ messages in thread From: Sergey V Turchin @ 2023-11-16 7:02 UTC (permalink / raw) To: ALT Linux Team development discussions 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. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [devel] NobodySubjectPolicy draft 2023-11-15 13:00 [devel] NobodySubjectPolicy draft Arseny Maslennikov 2023-11-15 13:42 ` Sergey V Turchin @ 2023-11-20 8:23 ` Sergey V Turchin 2023-11-20 8:41 ` Arseny Maslennikov 2023-11-20 11:22 ` Arseny Maslennikov ` (2 subsequent siblings) 4 siblings, 1 reply; 24+ messages in thread From: Sergey V Turchin @ 2023-11-20 8:23 UTC (permalink / raw) To: devel On Wednesday, 15 November 2023 16:00:56 MSK Arseny Maslennikov wrote: [...] > - Запретить установку файловых объектов под nobody с пакетами; У нас теперь есть 500 дополнительных UID для новых системных пользователей. Надеюсь, хватит. ;-) [...] -- Regards, Sergey. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [devel] NobodySubjectPolicy draft 2023-11-20 8:23 ` Sergey V Turchin @ 2023-11-20 8:41 ` Arseny Maslennikov 0 siblings, 0 replies; 24+ messages in thread From: Arseny Maslennikov @ 2023-11-20 8:41 UTC (permalink / raw) To: ALT Linux Team development discussions [-- 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 --] ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [devel] NobodySubjectPolicy draft 2023-11-15 13:00 [devel] NobodySubjectPolicy draft Arseny Maslennikov 2023-11-15 13:42 ` Sergey V Turchin 2023-11-20 8:23 ` Sergey V Turchin @ 2023-11-20 11:22 ` Arseny Maslennikov 2023-11-22 11:56 ` Arseny Maslennikov 2023-12-19 17:51 ` Arseny Maslennikov 4 siblings, 0 replies; 24+ messages in thread From: Arseny Maslennikov @ 2023-11-20 11:22 UTC (permalink / raw) To: ALT Linux Team development discussions [-- 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 --] ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [devel] NobodySubjectPolicy draft 2023-11-15 13:00 [devel] NobodySubjectPolicy draft Arseny Maslennikov ` (2 preceding siblings ...) 2023-11-20 11:22 ` Arseny Maslennikov @ 2023-11-22 11:56 ` Arseny Maslennikov 2023-12-19 17:51 ` Arseny Maslennikov 4 siblings, 0 replies; 24+ messages in thread From: Arseny Maslennikov @ 2023-11-22 11:56 UTC (permalink / raw) To: ALT Linux Team development discussions [-- 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 --] ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [devel] NobodySubjectPolicy draft 2023-11-15 13:00 [devel] NobodySubjectPolicy draft Arseny Maslennikov ` (3 preceding siblings ...) 2023-11-22 11:56 ` Arseny Maslennikov @ 2023-12-19 17:51 ` Arseny Maslennikov 4 siblings, 0 replies; 24+ messages in thread From: Arseny Maslennikov @ 2023-12-19 17:51 UTC (permalink / raw) To: ALT Linux Team development discussions [-- 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 --] ^ permalink raw reply [flat|nested] 24+ messages in thread
end of thread, other threads:[~2023-12-19 17:51 UTC | newest] Thread overview: 24+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2023-11-15 13:00 [devel] NobodySubjectPolicy draft Arseny Maslennikov 2023-11-15 13:42 ` Sergey V Turchin 2023-11-15 17:47 ` Arseny Maslennikov 2023-11-15 17:52 ` Arseny Maslennikov 2023-11-16 5:39 ` [devel] UserGroupPolicy ? Anton Farygin 2023-11-20 8:49 ` Arseny Maslennikov 2023-11-20 9:20 ` Anton Farygin 2023-11-20 12:25 ` Alexey Shabalin 2023-11-20 14:15 ` [devel] UID/GID pinning for packaged services Arseny Maslennikov 2023-11-20 14:36 ` Denis Medvedev 2023-11-20 15:48 ` Dmitry V. Levin 2023-11-16 6:55 ` [devel] NobodySubjectPolicy draft Sergey V Turchin 2023-11-16 7:57 ` Anton Farygin 2023-11-16 8:03 ` Sergey V Turchin 2023-11-16 8:33 ` Anton Farygin 2023-11-16 8:41 ` Sergey V Turchin 2023-11-16 8:52 ` Anton Farygin 2023-11-16 8:58 ` Sergey V Turchin 2023-11-16 7:02 ` Sergey V Turchin 2023-11-20 8:23 ` Sergey V Turchin 2023-11-20 8:41 ` Arseny Maslennikov 2023-11-20 11:22 ` Arseny Maslennikov 2023-11-22 11:56 ` Arseny Maslennikov 2023-12-19 17:51 ` Arseny Maslennikov
ALT Linux Team development discussions This inbox may be cloned and mirrored by anyone: git clone --mirror http://lore.altlinux.org/devel/0 devel/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 devel devel/ http://lore.altlinux.org/devel \ devel@altlinux.org devel@altlinux.ru devel@lists.altlinux.org devel@lists.altlinux.ru devel@linux.iplabs.ru mandrake-russian@linuxteam.iplabs.ru sisyphus@linuxteam.iplabs.ru public-inbox-index devel Example config snippet for mirrors. Newsgroup available over NNTP: nntp://lore.altlinux.org/org.altlinux.lists.devel AGPL code for this site: git clone https://public-inbox.org/public-inbox.git