The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]



"Понижение привилегий root с помощью file capability (CAP)."
Вариант для распечатки  
Пред. тема | След. тема 
Форум Информационная безопасность (Linux привязка / Linux)
Изначальное сообщение [ Отслеживать ]

"Понижение привилегий root с помощью file capability (CAP)."  +/
Сообщение от Аноним (0), 23-Мрт-22, 17:55 
Скрипты с:
setpriv ...
capsh ...
...
не предлагать!

Править исходники на C для сброса привилегий - не предлагать.

Сыстемды сервисы с cap - не предлагать.

Патчи Capability-NG от Google заманчивые, это то что в принципе подходит, но не предлагать. ;)

Хочу чисто существующими xattr file capability права на файл установить так, чтобы root его запускал и процесс имел пониженные привилегии.

setcap ...

Просмотреть привилегии можно например в pscap.

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения [Сортировка по ответам | RSS]

1. Сообщение от Павел Отредиез (ok), 23-Мрт-22, 21:41   +/
>[оверквотинг удален]
> ...
> не предлагать!
> Править исходники на C для сброса привилегий - не предлагать.
> Сыстемды сервисы с cap - не предлагать.
> Патчи Capability-NG от Google заманчивые, это то что в принципе подходит, но
> не предлагать. ;)
> Хочу чисто существующими xattr file capability права на файл установить так, чтобы
> root его запускал и процесс имел пониженные привилегии.
> setcap ...
> Просмотреть привилегии можно например в pscap.

setcap только устанавливает для не рута. Можно общесистемно отключить нужные capabilities. Тебе подойдёт?

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #3, #4

2. Сообщение от Павел Отредиез (ok), 23-Мрт-22, 21:42   +/
>[оверквотинг удален]
> ...
> не предлагать!
> Править исходники на C для сброса привилегий - не предлагать.
> Сыстемды сервисы с cap - не предлагать.
> Патчи Capability-NG от Google заманчивые, это то что в принципе подходит, но
> не предлагать. ;)
> Хочу чисто существующими xattr file capability права на файл установить так, чтобы
> root его запускал и процесс имел пониженные привилегии.
> setcap ...
> Просмотреть привилегии можно например в pscap.

Какую задачу ты решаешь? Может наоборот для не рута выставить нужные cap?

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #6, #8

3. Сообщение от Павел Отредиез (ok), 23-Мрт-22, 22:05   +/
setcap это замена root suid бита нарезанная на лоскутки. Так не отнять капы у рута. Это вообще наверное не возможно без патчей. Патчи есть.


Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #5, #7

4. Сообщение от Аноним (5), 24-Мрт-22, 05:49   +/
Не очень, но давай. Собрал аж 12 cap которые не используются, их можно отключить общесистемно. Эффект для безопасности - почти никакой.

Задача управлять CAP на уровне файла запускаемого от root.

Уровень пользователя не подходит. А в /etc/security/capability.conf можно root привилегии порезать?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

5. Сообщение от Аноним (5), 24-Мрт-22, 05:52   +/
> Так не отнять капы у рута. Это вообще наверное не возможно без патчей. Патчи есть.

Какие? Capability-NG от Google?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3

6. Сообщение от Аноним (5), 24-Мрт-22, 06:15   +/
> Какую задачу ты решаешь?

Отнимать права у процесов при запуске от root определенных файлов с помощью xattr. Именно то, что сделано Google с помощью capability-ng

> Может наоборот для не рута выставить нужные cap?

Нет, этого делать не стоит совсем. Некоторые идут неверным путем создания "мелкого рута": https://www.linuxjournal.com/magazine/making-root-unprivileged

Но там граблей немерено: https://book.hacktricks.xyz/linux-unix/privilege-escalation/...

Интересна статистика по дистрам:
Название и версия дистрибутива
Вывод getcap -r / 2>/dev/null

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2

7. Сообщение от Аноним (5), 24-Мрт-22, 07:03   +/
> Так не отнять капы у рута. Это вообще наверное не возможно без патчей. Патчи есть.

Давно уже с помощью MAC можно отнимать, пофайлово, привилегии CAP у root процесса.

Как раз смотря на простыни политик MAC мне и захотелось иметь возможность с помощью XATTR отнимать, пофайлово, привилегии CAP у root процессов.

Можно сказать, что я очень ленив, а мне надо результат максимально просто.

Править код C - сложно.

Поддерживать кучу скриптов с setpriv, capsh и настройки сыстемды с cap - сложно.

Поддерживать политики MAC с пофайлово указанными CAP для root - сложно.

XATTR с необходимыми CAP для файла - самое простое и правильное решение этой задачи.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3

8. Сообщение от Аноним (8), 24-Мрт-22, 11:13   +/
> для не рута выставить нужные cap?

А как выставить нужные CAP для не root, правельно, в плане безопасности?

1. Мнение разрабов дистрибутива:
groupadd wireshark
usermod -a -G wireshark vasya
chown root:wireshark /usr/bin/dumpcap
chmod a-rwxst,u+rwx,g+x /usr/bin/dumpcap
setcap cap_dac_read_search,cap_net_admin,cap_net_raw=ep /usr/bin/dumpcap

2 Мое мнение:
chmod go-rwst /usr/bin/dumpcap
setcap cap_dac_read_search,cap_net_admin,cap_net_raw=i /usr/bin/dumpcap
В файле /etc/security/capability.conf добавляем строку:
cap_dac_read_search,cap_net_admin,cap_net_raw   vasya
В файле /etc/pam.d/auth/system-auth добавляем строку:
auth   required   pam_cap.so

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #9

9. Сообщение от Павел Отредиез (ok), 24-Мрт-22, 18:35   +/
>> для не рута выставить нужные cap?
> А как выставить нужные CAP для не root, правельно, в плане безопасности?

В первом случае капы даются только на бинарник. Во втором Васе вообще. С точки зрения безопасности первый вариант уже и лучше. Второй слишком много прав.


Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #10

10. Сообщение от Аноним (10), 25-Мрт-22, 11:01   +/
> В первом случае капы даются только на бинарник. Во втором Васе вообще.
> С точки зрения безопасности первый вариант уже и лучше. Второй слишком много прав.

Садись, двойка.

В первом случае права CAP даются на бинарник всем, а с помощью DAC право запускать бинарь разрешают только группе wiresharck. Таким образом права CAP фактически получат только члены этой группы и только на процесс dumpcap.

Во втором случае в /etc/security/capability.conf, пользователю дается только возможность наследовать определенные права CAP, а сами права он получает только при исполнении файла для которого установлены эти права с битом наследования. Таким образом права CAP фактически получит только определенные в /etc/security/capability.conf пользователи и только на процесс dumpcap.

Заметь разницу:

Вариант 1
setcap cap_dac_read_search,cap_net_admin,cap_net_raw=ep /usr/bin/dumpcap

Вариант 2
setcap cap_dac_read_search,cap_net_admin,cap_net_raw=i /usr/bin/dumpcap

PS: как права root порезать знаешь? Ссылки на патчи есть?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9

11. Сообщение от Аноним (11), 30-Мрт-22, 18:13   +/
Что никому здесь CAP не нужны?

Google в Android умеет сбрасывать права root своим init: https://chromium.googlesource.com/aosp/platform/system/core/...

"If no capabilities are provided, then all capabilities are removed from this service, even if it runs as root."


До ядра 2.6.25 права резались общесистемно, а в новых версиях заявлена по поточна поддержка прав. В Linux на каждый процесс можно выставить свои права.

Общесистемные, доступные права в /proc/sys/kernel/cap-bound можно было когдато редактировать lcap: https://www.debian.org/doc/manuals/securing-debian-manual/ch...

lcap - A user friendly interface to remove capabilities (kernel-based access control) in the kernel, making the system more secure. For example, executing lcap CAP_SYS_MODULE will remove module loading capabilities (even for the root user).

CapInh для root можно выставить в /etc/security/capabilities.conf как сбросить права root процессов с помощью XATTR security.capability?

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #12

12. Сообщение от Аноним (12), 19-Апр-22, 15:35   +/
> Что никому здесь CAP не нужны?

Всем нужны, но все стесняются поднять этот вопрос.

У меня от root для ВСЕХ задач запускаются ~50 программ. Все необходимые и достаточные CAP для этих 50 прог собрал. Это всего ~50 строк простейшего кода, который выставит необходимые и достаточные привилегии для этих прог с битом наследования.

В /etc/security/capability.conf прописать:
перечень,необходимых,и,достаточных,прав   root
# а остальным все запретить:
none *

Вот только дырявое ведро линукса согласно
    man 7 capabilities https://man7.org/linux/man-pages/man7/capabilities.7.html
Не хочет обрабатывать права для root тупо в permitted и effective записывая все без фильтра.

Надо бы опцию какюто в .config и параметрах загрузки ядра иметь, чтобы для root CAP обрабатывались, как для обычного пользователя!

Есть еще вариантант СТРАШНЫЙ КОСТЫЛЬ:

https://man7.org/linux/man-pages/man7/capabilities.7.html

Set-user-ID-root programs that have file capabilities
       There is one exception to the behavior described under
       Capabilities and execution of programs by root.  If (a) the
       binary that is being executed has capabilities attached and (b)
       the real user ID of the process is not 0 (root) and (c) the
       effective user ID of the process is 0 (root), then the file
       capability bits are honored (i.e., they are not notionally
       considered to be all ones).  The usual way in which this
       situation can arise is when executing a set-UID-root program that
       also has file capabilities.  When such a program is executed, the
       process gains just the capabilities granted by the program (i.e.,
       not all capabilities, as would occur when executing a set-user-
       ID-root program that does not have any associated file
       capabilities).

       Note that one can assign empty capability sets to a program file,
       and thus it is possible to create a set-user-ID-root program that
       changes the effective and saved set-user-ID of the process that
       executes the program to 0, but confers no capabilities to that
       process.

Надо кроме inhirit CAP ставить еще s-bit, и запускать процесс под обычным пользователем с прописанными возможными правами в:  /etc/security/capability.conf

Кто что скажет по этому варианту?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11

13. Сообщение от Аноним (13), 28-Фев-23, 08:06   +/
> исследование показало неожиданные результаты: 19 из 35 существующих "capabilities" позволили совершить действия, которые в конечном итоге потенциально могут привести к получению полноценных прав пользователя root.

https://www.opennet.ru/opennews/art.shtml?num=29219

http://forums.grsecurity.net/viewtopic.php?f=7&t=2522

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #14

14. Сообщение от Аноним (14), 28-Фев-23, 14:06   +/
Все равно лучше CAP чем нечего. Привилегии root процессов разать надо.

Кто-то выще малтикса на уровне B3 что-то когдато делал? Есть ссылки по успешному использованию capabilities для ограичения root в GNU/Linux дистрах?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13


Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру