[devel] Q: пора разрешать privileged executables явно на уровне дистрибутивов?

[devel] Q: пора разрешать privileged executables явно на уровне дистрибутивов?

[Dmitry V. Levin]

On Wed, Jan 12, 2022 at 04:34:06AM +0000, QA Team Robot wrote:
> 	2 NEW bugs
[...]
> #41695	libgtop         	normal  	 ---
> Содержит suid-бинарник

Я думаю, есть смысл, чтобы ядро за этим следило.
Загружаешь ему список разрешённых privileged executables,
все остальные запрещены.


-- 
ldv

Re: [devel] Q: пора разрешать privileged executables явно на уровне дистрибутивов?

[Vladimir D. Seleznev]

On Wed, Jan 12, 2022 at 08:10:10PM +0300, Dmitry V. Levin wrote:
> On Wed, Jan 12, 2022 at 04:34:06AM +0000, QA Team Robot wrote:
> > 	2 NEW bugs
> [...]
> > #41695	libgtop         	normal  	 ---
> > Содержит suid-бинарник
> 
> Я думаю, есть смысл, чтобы ядро за этим следило.
> Загружаешь ему список разрешённых privileged executables,
> все остальные запрещены.

Лучше сопровождать белый список suid-бинарников, которые можно собирать
в репозитории (с привязкой к пакетам, в которых они упакованы). И
дополнять этот список только после вычитки кода инженером безопасности.

-- 
   WBR,
   Vladimir D. Seleznev

Re: [devel] Q: пора разрешать privileged executables явно на уровне дистрибутивов?

[Vladimir D. Seleznev]

On Wed, Jan 12, 2022 at 09:00:49PM +0300, Vladimir D. Seleznev wrote:
> On Wed, Jan 12, 2022 at 08:10:10PM +0300, Dmitry V. Levin wrote:
> > On Wed, Jan 12, 2022 at 04:34:06AM +0000, QA Team Robot wrote:
> > > 	2 NEW bugs
> > [...]
> > > #41695	libgtop         	normal  	 ---
> > > Содержит suid-бинарник
> > 
> > Я думаю, есть смысл, чтобы ядро за этим следило.
> > Загружаешь ему список разрешённых privileged executables,
> > все остальные запрещены.
> 
> Лучше сопровождать белый список suid-бинарников, которые можно собирать
> в репозитории (с привязкой к пакетам, в которых они упакованы). И
> дополнять этот список только после вычитки кода инженером безопасности.

Как, например, это сделано в SUSE:

https://en.opensuse.org/openSUSE:Package_security_guidelines#Setuid_Binaries

-- 
   WBR,
   Vladimir D. Seleznev

Re: [devel] Q: пора разрешать privileged executables явно на уровне дистрибутивов?

[Dmitry V. Levin]

On Wed, Jan 12, 2022 at 09:00:49PM +0300, Vladimir D. Seleznev wrote:
> On Wed, Jan 12, 2022 at 08:10:10PM +0300, Dmitry V. Levin wrote:
> > On Wed, Jan 12, 2022 at 04:34:06AM +0000, QA Team Robot wrote:
> > > 	2 NEW bugs
> > [...]
> > > #41695	libgtop         	normal  	 ---
> > > Содержит suid-бинарник
> > 
> > Я думаю, есть смысл, чтобы ядро за этим следило.
> > Загружаешь ему список разрешённых privileged executables,
> > все остальные запрещены.
> 
> Лучше сопровождать белый список suid-бинарников, которые можно собирать
> в репозитории (с привязкой к пакетам, в которых они упакованы). И
> дополнять этот список только после вычитки кода инженером безопасности.

Белый список для всего репозитория получается недостаточно гибким.
Допустим, ты делаешь какой-нибудь дистрибутив и не можешь не включить
туда какой-нибудь суидный файл, например, тот же pkexec, хотя на localhost
ты бы такой суидный файл и за версту бы не подпустил.


-- 
ldv

Re: [devel] Q: пора разрешать privileged executables явно на уровне дистрибутивов?

[Vladimir D. Seleznev]

On Wed, Jan 12, 2022 at 09:07:23PM +0300, Dmitry V. Levin wrote:
> On Wed, Jan 12, 2022 at 09:00:49PM +0300, Vladimir D. Seleznev wrote:
> > On Wed, Jan 12, 2022 at 08:10:10PM +0300, Dmitry V. Levin wrote:
> > > On Wed, Jan 12, 2022 at 04:34:06AM +0000, QA Team Robot wrote:
> > > > 	2 NEW bugs
> > > [...]
> > > > #41695	libgtop         	normal  	 ---
> > > > Содержит suid-бинарник
> > > 
> > > Я думаю, есть смысл, чтобы ядро за этим следило.
> > > Загружаешь ему список разрешённых privileged executables,
> > > все остальные запрещены.
> > 
> > Лучше сопровождать белый список suid-бинарников, которые можно собирать
> > в репозитории (с привязкой к пакетам, в которых они упакованы). И
> > дополнять этот список только после вычитки кода инженером безопасности.
> 
> Белый список для всего репозитория получается недостаточно гибким.
> Допустим, ты делаешь какой-нибудь дистрибутив и не можешь не включить
> туда какой-нибудь суидный файл, например, тот же pkexec, хотя на localhost
> ты бы такой суидный файл и за версту бы не подпустил.

Одно другому вроде не должно мешать. Если сделать некий whitelist в ядре
по-умолчанию, то это может нарушить принцип наименьшего удивления, хотя
сама идея, чтобы это контролировалось ядром, мне нравится (altha это
умеет). В случае белого же списка для репозитории будет явно известно,
какие suid-бинарники могут быть, и не возникнет по-умолчанию ситуации,
что суид есть, но он не работает.

-- 
   WBR,
   Vladimir D. Seleznev

Re: [devel] Q: пора разрешать privileged executables явно на уровне дистрибутивов?

[Dmitry V. Levin]

On Wed, Jan 12, 2022 at 09:23:03PM +0300, Vladimir D. Seleznev wrote:
> On Wed, Jan 12, 2022 at 09:07:23PM +0300, Dmitry V. Levin wrote:
> > On Wed, Jan 12, 2022 at 09:00:49PM +0300, Vladimir D. Seleznev wrote:
> > > On Wed, Jan 12, 2022 at 08:10:10PM +0300, Dmitry V. Levin wrote:
> > > > On Wed, Jan 12, 2022 at 04:34:06AM +0000, QA Team Robot wrote:
> > > > > 	2 NEW bugs
> > > > [...]
> > > > > #41695	libgtop         	normal  	 ---
> > > > > Содержит suid-бинарник
> > > > 
> > > > Я думаю, есть смысл, чтобы ядро за этим следило.
> > > > Загружаешь ему список разрешённых privileged executables,
> > > > все остальные запрещены.
> > > 
> > > Лучше сопровождать белый список suid-бинарников, которые можно собирать
> > > в репозитории (с привязкой к пакетам, в которых они упакованы). И
> > > дополнять этот список только после вычитки кода инженером безопасности.
> > 
> > Белый список для всего репозитория получается недостаточно гибким.
> > Допустим, ты делаешь какой-нибудь дистрибутив и не можешь не включить
> > туда какой-нибудь суидный файл, например, тот же pkexec, хотя на localhost
> > ты бы такой суидный файл и за версту бы не подпустил.
> 
> Одно другому вроде не должно мешать.

Любой белый список suid executables на уровне репозитория будет создавать
ощущение ложной безопасности, и вряд ли принесёт какую-нибудь пользу,
за исключением фильтрации совсем уж случайных suid executables.
Зато его придётся мантейнить, будут непрекращающиеся споры.  Зачем?

Вот что можно было бы полезного сделать на уровне репозитория, так это
запретить такие suid executables, которые по умолчанию доступны для
запуска всем без исключения.

> по-умолчанию, то это может нарушить принцип наименьшего удивления, хотя
> сама идея, чтобы это контролировалось ядром, мне нравится (altha это
> умеет).

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


-- 
ldv

Re: [devel] Q: пора разрешать privileged executables явно на уровне дистрибутивов?

[Vladimir D. Seleznev]

On Thu, Jan 13, 2022 at 02:12:53AM +0300, Dmitry V. Levin wrote:
> On Wed, Jan 12, 2022 at 09:23:03PM +0300, Vladimir D. Seleznev wrote:
> > On Wed, Jan 12, 2022 at 09:07:23PM +0300, Dmitry V. Levin wrote:
> > > On Wed, Jan 12, 2022 at 09:00:49PM +0300, Vladimir D. Seleznev wrote:
> > > > On Wed, Jan 12, 2022 at 08:10:10PM +0300, Dmitry V. Levin wrote:
> > > > > On Wed, Jan 12, 2022 at 04:34:06AM +0000, QA Team Robot wrote:
> > > > > > 	2 NEW bugs
> > > > > [...]
> > > > > > #41695	libgtop         	normal  	 ---
> > > > > > Содержит suid-бинарник
> > > > > 
> > > > > Я думаю, есть смысл, чтобы ядро за этим следило.
> > > > > Загружаешь ему список разрешённых privileged executables,
> > > > > все остальные запрещены.
> > > > 
> > > > Лучше сопровождать белый список suid-бинарников, которые можно собирать
> > > > в репозитории (с привязкой к пакетам, в которых они упакованы). И
> > > > дополнять этот список только после вычитки кода инженером безопасности.
> > > 
> > > Белый список для всего репозитория получается недостаточно гибким.
> > > Допустим, ты делаешь какой-нибудь дистрибутив и не можешь не включить
> > > туда какой-нибудь суидный файл, например, тот же pkexec, хотя на localhost
> > > ты бы такой суидный файл и за версту бы не подпустил.
> > 
> > Одно другому вроде не должно мешать.
> 
> Любой белый список suid executables на уровне репозитория будет создавать
> ощущение ложной безопасности, и вряд ли принесёт какую-нибудь пользу,
> за исключением фильтрации совсем уж случайных suid executables.

Ну, как сказать.

На срезе Сизифа от 13 января 2022 года архитектуры x86_64 явно упаковано
116 suid-бинарников в 74 пакетах (и только в 9 из них упакованы
control'ы), собранных из 67 исходников, и только 39 из этих бинарников
запрещены от исполнения для others.

При этом, это явно не все suid-бинарники, т.к. некоторые выставляют
suid-бит в postinstall-скриптах, но автоматизировать их выявление
возможно установкой каждого пакета.

Абсурдная ситуация: более доверенные исполняемые файлы покрыты
control'ами или защищены от исполнения через группу-владельца, а менее
доверенные — нет.

> Зато его придётся мантейнить, будут непрекращающиеся споры.  Зачем?

А это плохо? Может, споров будет и не так много?

Сходу, взглянув на список, мне кажется, что некоторые suid-биты
поставлены избыточно, по ошибке или по не знанию. Например, для
бинарников, реализующих/монтирующих файловые системы через fuse, на
самом деле не нужен suid-бит (его достаточно на fusermount).

> Вот что можно было бы полезного сделать на уровне репозитория, так это
> запретить такие suid executables, которые по умолчанию доступны для
> запуска всем без исключения.
> 
> > по-умолчанию, то это может нарушить принцип наименьшего удивления, хотя
> > сама идея, чтобы это контролировалось ядром, мне нравится (altha это
> > умеет).
> 
> Ну так использовать надо, раз умеет.  Хотя я бы предпочёл какое-нибудь
> более простое решение.

-- 
   WBR,
   Vladimir D. Seleznev

Re: [devel] Q: пора разрешать privileged executables явно на уровне дистрибутивов?

[Alexey V. Vissarionov]

On 2022-01-12 21:00:49 +0300, Vladimir D. Seleznev wrote:

 >>> #41695	libgtop		normal	 ---
 >>> Содержит suid-бинарник
 >> Я думаю, есть смысл, чтобы ядро за этим следило.
 >> Загружаешь ему список разрешённых privileged executables,
 >> все остальные запрещены.
 > Лучше сопровождать белый список suid-бинарников, которые можно
 > собирать в репозитории (с привязкой к пакетам, в которых они
 > упакованы). И дополнять этот список только после вычитки кода
 > инженером безопасности.

Это две независимые задачи.

Первая - что можно запускать как SUID. Влили список через sysctl,
потом дали указание отключить этот интерфейс (точно так же, как
/proc/sys/kernel/modules_disabled), и все: запустить бинарь можно,
но SUID не работает. И список уже хрен поменяешь - только если в
/etc/suid.d файл добавить и перезагрузиться. Мне оно видится как
файл + umask, кстати: 4 - разрешен SUID, 2 - разрешен SGID, 6 -
разрешены SUID и SGID, какой бы дикостью это ни было, ибо o+x).

Вторая - что можно собирать в репу. В идеале, конечно, SUID-бинарей
в системе вообще быть не должно, но всем понятно, что бы живем в
неидеальном мире. И как минимум предупреждение о том, что какая-то
софтина пытается протащить SUID-бинарь будет весьма полезно (а кому
очень надо, добавят "suid" в no_sisyphus_check и соберут локально;
мы же этого будем максимально избегать).


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net

Re: [devel] Q: пора разрешать privileged executables явно на уровне дистрибутивов?

[Michael Shigorin]

On Wed, Jan 12, 2022 at 09:52:19PM +0300, Alexey V. Vissarionov wrote:
> >> Я думаю, есть смысл, чтобы ядро за этим следило.
> > Лучше сопровождать белый список suid-бинарников
> Это две независимые задачи.

+1

> Первая - что можно запускать как SUID. Влили список через sysctl,
> потом дали указание отключить этот интерфейс (точно так же, как
> /proc/sys/kernel/modules_disabled), и все: запустить бинарь можно,
> но SUID не работает. И список уже хрен поменяешь - только если в
> /etc/suid.d файл добавить и перезагрузиться. Мне оно видится как
> файл + umask, кстати: 4 - разрешен SUID, 2 - разрешен SGID, 6 -
> разрешены SUID и SGID, какой бы дикостью это ни было, ибо o+x).
> 
> Вторая - что можно собирать в репу. В идеале, конечно, SUID-бинарей
> в системе вообще быть не должно, но всем понятно, что бы живем в
> неидеальном мире. И как минимум предупреждение о том, что какая-то
> софтина пытается протащить SUID-бинарь будет весьма полезно (а кому
> очень надо, добавят "suid" в no_sisyphus_check и соберут локально;
> мы же этого будем максимально избегать).

Не знаю, чем именно делается checkinstall, но туда бы и добавить
проверку (не)появления новых suid/sgid binaries в процессе
установки пакета -- как раз на случай мухлежа в %post с целью
обхода 140-check-perms.

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

Re: [devel] Q: пора разрешать privileged executables явно на уровне дистрибутивов?

[Gleb Fotengauer-Malinovskiy]

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

Hi,

On Thu, Jan 13, 2022 at 12:51:28AM +0300, Sergei Epiphanov wrote:
> 
> "Dmitry V. Levin" <ldv@altlinux.org> 12 января 2022 г. 20:10:13 написал:
> 
> > On Wed, Jan 12, 2022 at 04:34:06AM +0000, QA Team Robot wrote:
> >> 2 NEW bugs
> > [...]
> >> #41695 libgtop         normal   ---
> >> Содержит suid-бинарник
> >
> > Я думаю, есть смысл, чтобы ядро за этим следило.
> > Загружаешь ему список разрешённых privileged executables,
> > все остальные запрещены.
> 
> Мне это не очень нравится.
> Во-первых, suid можно заменить на запуск через sudo или su.

И это всяко лучше, чем использование непроверенных suid-ных программ, а
задача состоит именно в ограничении вреда от них.

> Второе. Подменить "белый" файл на другой физически.

Очевидно, что такая система взломана уже без возможности восстановления
доверия к ней.

> Третье. А если потребуется дополнить систему своим пакетом со своим
> suid-файлом? 

Например, существующий уже сейчас в ядрах LSM-модуль altha предоставляет
для этого интерфейс:

* kernel.altha.nosuid.enabled = 0, set to 1 to enable
* kernel.altha.nosuid.exceptions =, colon-separated list of enabled SUID
  binaries, for example: ``/bin/su:/usr/libexec/hasher-priv/hasher-priv``

-- 
glebfm

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

Re: [devel] Q: пора разрешать privileged executables явно на уровне дистрибутивов?

[Vladimir D. Seleznev]

On Thu, Jan 13, 2022 at 09:07:45AM +0300, Sergei Epiphanov wrote:
> 
> 
> Gleb Fotengauer-Malinovskiy <glebfm@altlinux.org> 13 января 2022 г. 
> 01:18:29 написал:
> 
> > Hi,
> >
> > On Thu, Jan 13, 2022 at 12:51:28AM +0300, Sergei Epiphanov wrote:
> >>
> >> "Dmitry V. Levin" <ldv@altlinux.org> 12 января 2022 г. 20:10:13 написал:
> >>
> >>> On Wed, Jan 12, 2022 at 04:34:06AM +0000, QA Team Robot wrote:
> >>>> 2 NEW bugs
> >>> [...]
> >>>> #41695 libgtop         normal   ---
> >>>> Содержит suid-бинарник
> >>>
> >>> Я думаю, есть смысл, чтобы ядро за этим следило.
> >>> Загружаешь ему список разрешённых privileged executables,
> >>> все остальные запрещены.
> >>
> >> Мне это не очень нравится.
> >> Во-первых, suid можно заменить на запуск через sudo или su.
> >
> > И это всяко лучше, чем использование непроверенных suid-ных программ, а
> > задача состоит именно в ограничении вреда от них.
> 
> Здесь как раз и проблема. Пример я уже привёл. Приходится ставить на 
> команду выполнение sudo без пароля, что позволяет пользователю самому 
> рулить программой через sudo.

Так идея не в том, чтобы не позволять пользователю рулить системой
(совсем даже наоборот).

Если вы ставите команду на выполнение через sudo без пароля, вы это
делаете явно, и явно запускаете команду.

Проблема же произвольных suid-бинарников в том, что при правах доступа
не строже 4xx1 (*) любой пользователь может её запустить (в т.ч.
злонамеренный или скомпрометированный), тем самым повысив себе
привилегии.  И даже если процесс сэндбоксится, сбрасывает привилегии,
всё-равно есть возможность пытаться сколь угодно долго (*) выполнить
произвольный код в привилегированном окружении до наступления успеха,
при этом эксплуатируемая ошибка не обязательно должна быть при этом
именно в запускаемом суидном бинарнике.

Но в любом случае решение, как управлять системой остаётся за
пользователем в зависимости от его модели угроз.

* В одном проекте была реализована функциональность, запрещающая на
некоторое время запускать suid-ные команды пользователю, у которого
анормально завершил работу setuid'ный процесс.

P.S. Re: sudo: why not?
https://www.openwall.com/lists/owl-users/2004/10/20/6

-- 
   WBR,
   Vladimir D. Seleznev

Re: [devel] Q: пора разрешать privileged executables явно на уровне дистрибутивов?

[Aleksei Nikiforov]

13.01.2022 09:48, Vladimir D. Seleznev пишет:
> On Thu, Jan 13, 2022 at 09:07:45AM +0300, Sergei Epiphanov wrote:
>>
>>
>> Gleb Fotengauer-Malinovskiy <glebfm@altlinux.org> 13 января 2022 г.
>> 01:18:29 написал:
>>
>>> Hi,
>>>
>>> On Thu, Jan 13, 2022 at 12:51:28AM +0300, Sergei Epiphanov wrote:
>>>>
>>>> "Dmitry V. Levin" <ldv@altlinux.org> 12 января 2022 г. 20:10:13 написал:
>>>>
>>>>> On Wed, Jan 12, 2022 at 04:34:06AM +0000, QA Team Robot wrote:
>>>>>> 2 NEW bugs
>>>>> [...]
>>>>>> #41695 libgtop         normal   ---
>>>>>> Содержит suid-бинарник
>>>>>
>>>>> Я думаю, есть смысл, чтобы ядро за этим следило.
>>>>> Загружаешь ему список разрешённых privileged executables,
>>>>> все остальные запрещены.
>>>>
>>>> Мне это не очень нравится.
>>>> Во-первых, suid можно заменить на запуск через sudo или su.
>>>
>>> И это всяко лучше, чем использование непроверенных suid-ных программ, а
>>> задача состоит именно в ограничении вреда от них.
>>
>> Здесь как раз и проблема. Пример я уже привёл. Приходится ставить на
>> команду выполнение sudo без пароля, что позволяет пользователю самому
>> рулить программой через sudo.
> 
> Так идея не в том, чтобы не позволять пользователю рулить системой
> (совсем даже наоборот).
> 
> Если вы ставите команду на выполнение через sudo без пароля, вы это
> делаете явно, и явно запускаете команду.
> 
> Проблема же произвольных suid-бинарников в том, что при правах доступа
> не строже 4xx1 (*) любой пользователь может её запустить (в т.ч.
> злонамеренный или скомпрометированный), тем самым повысив себе
> привилегии.  И даже если процесс сэндбоксится, сбрасывает привилегии,
> всё-равно есть возможность пытаться сколь угодно долго (*) выполнить
> произвольный код в привилегированном окружении до наступления успеха,
> при этом эксплуатируемая ошибка не обязательно должна быть при этом
> именно в запускаемом суидном бинарнике.
> 
> Но в любом случае решение, как управлять системой остаётся за
> пользователем в зависимости от его модели угроз.
> 
> * В одном проекте была реализована функциональность, запрещающая на
> некоторое время запускать suid-ные команды пользователю, у которого
> анормально завершил работу setuid'ный процесс.
> 
> P.S. Re: sudo: why not?
> https://www.openwall.com/lists/owl-users/2004/10/20/6
> 

Здравствуйте.

Могу ещё предложить whitelist на уровне пакетного менеджера. При 
установке или обновлении пакета, если в нём есть suid/sgid файлы, 
сравнивать их с разрешённым списком в пакетном менеджере, и если этот 
файл в списке отсутствует, то suid/sgid снимать. Также можно при этом 
проверять что этот файл из определённого пакета, а в пакетном менеджере 
включать/выключать эту фичу. Такой список будет более гибким чем в 
сборочнице, а в сравнении с ядром - зависит от реализаций.

С уважением,
Алексей Никифоров

Re: [devel] Q: пора разрешать privileged executables явно на уровне дистрибутивов?

[Anton Farygin]

On 13.01.2022 10:23, Aleksei Nikiforov wrote:
>>
>> P.S. Re: sudo: why not?
>> https://www.openwall.com/lists/owl-users/2004/10/20/6
>>
>
> Здравствуйте.
>
> Могу ещё предложить whitelist на уровне пакетного менеджера. При 
> установке или обновлении пакета, если в нём есть suid/sgid файлы, 
> сравнивать их с разрешённым списком в пакетном менеджере, и если этот 
> файл в списке отсутствует, то suid/sgid снимать. Также можно при этом 
> проверять что этот файл из определённого пакета, а в пакетном 
> менеджере включать/выключать эту фичу. Такой список будет более гибким 
> чем в сборочнице, а в сравнении с ядром - зависит от реализаций. 

Да это ерунда - пользователи отлично умеют устанавливать софт минуя 
пакетный менеджер.

Лучше, всё-таки, на уровне ядра.

Re: [devel] Q: пора разрешать privileged executables явно на уровне дистрибутивов?

[Vladimir D. Seleznev]

On Thu, Jan 13, 2022 at 10:23:00AM +0300, Aleksei Nikiforov wrote:
> 13.01.2022 09:48, Vladimir D. Seleznev пишет:
> [...]
> 
> Здравствуйте.

Hi!

> Могу ещё предложить whitelist на уровне пакетного менеджера. При 
> установке или обновлении пакета, если в нём есть suid/sgid файлы, 
> сравнивать их с разрешённым списком в пакетном менеджере, и если этот 
> файл в списке отсутствует, то suid/sgid снимать. Также можно при этом 
> проверять что этот файл из определённого пакета, а в пакетном менеджере 
> включать/выключать эту фичу. Такой список будет более гибким чем в 
> сборочнице, а в сравнении с ядром - зависит от реализаций.

Мне кажется, или вы имеете в виду control(8)? :)

-- 
   WBR,
   Vladimir D. Seleznev

Re: [devel] Q: пора разрешать privileged executables явно на уровне дистрибутивов?

[Anton Farygin]

On 13.01.2022 10:29, Vladimir D. Seleznev wrote:
> On Thu, Jan 13, 2022 at 10:23:00AM +0300, Aleksei Nikiforov wrote:
>> 13.01.2022 09:48, Vladimir D. Seleznev пишет:
>> [...]
>>
>> Здравствуйте.
> Hi!
>
>> Могу ещё предложить whitelist на уровне пакетного менеджера. При
>> установке или обновлении пакета, если в нём есть suid/sgid файлы,
>> сравнивать их с разрешённым списком в пакетном менеджере, и если этот
>> файл в списке отсутствует, то suid/sgid снимать. Также можно при этом
>> проверять что этот файл из определённого пакета, а в пакетном менеджере
>> включать/выключать эту фичу. Такой список будет более гибким чем в
>> сборочнице, а в сравнении с ядром - зависит от реализаций.
> Мне кажется, или вы имеете в виду control(8)? :)
>
Только принудительный.

Re: [devel] Q: пора разрешать privileged executables явно на уровне дистрибутивов?

[Anton V. Boyarshinov]

В Thu, 13 Jan 2022 01:17:04 +0300
Gleb Fotengauer-Malinovskiy <glebfm@altlinux.org> пишет:

> Например, существующий уже сейчас в ядрах LSM-модуль altha предоставляет
> для этого интерфейс:
> 
> * kernel.altha.nosuid.enabled = 0, set to 1 to enable
> * kernel.altha.nosuid.exceptions =, colon-separated list of enabled SUID
>   binaries, for example: ``/bin/su:/usr/libexec/hasher-priv/hasher-priv``

Пожалуй, у этого интерфейса, есть определённые недостатки. А именно,
неудобно собирать этот список из каких либо .d файлов (хотя можно
сделать обработчик .d файлов, который будет генерировать конфиг для
sysctl или прямо выполнять sysctl)