Как разрешить обычному пользователю менять MAC-адрес

Судя по ману cap_net_admin и правда должен давать туда доступ. Ну, возможно забыли или специально сделали исключение.

chown root:netdev /usr/sbin/ip
chmod o-rwxst /usr/sbin/ip

Смотреть в логах какая подсистема безопасности запрещает доступ. Учитывай что CAP, MAC, Linux kernel могут запрещать доступ одновременно, надо, чтобы разрешали все подсистемы. Linux 6.16 говорят имеет логи, или патчи grsecurity использовать они дают хорошие логи.

https://www.opennet.ru/openforum/vsluhforumID10/5622.html#8

Учитывай что CAP, MAC, Linux kernel могут запрещать доступ одновременно, надо, чтобы разрешали все подсистемы.

«CAP и MAC» это тоже linux kernel, если что.

Да, но MAC может иметь свои отдельные хуки в ядре и блокировать привилегии не зависимо от CAP. Например RSBAC (gradm) от grsecurity будет блокировать привилегии не зависимо, от того что там в file capabilities нараздавали.

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

CAP крутая вещь, оно проще MAC, а безопасности даёт очень много! Поправил себе init скрипты, чтобы все рутовые процессы запускались с необходимыми и достаточными правами. pscap full ниукого нет.

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

Если тебе CAP что-то дал это значит «ядро разрешило». Потому что CAP - это ядро и есть. Как и все остальные аспекты доступа, они все в ядре.

А файловые CAP в твоём дистрибутиве вообще работают? Посмотреть можно по утелите ping ей cap_net_raw для открытия сокета необходим:

getcap /bin/ping

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

Вроде да:

$ getcap /bin/ping
/bin/ping cap_net_raw=ep

sudo без пароля + шаблон команды с аргументами и вот уже никакого пердолинга с капсами.

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

Operation not permitted

Это обычно не связано с правами.

Да, но под рутом и sudo он такого не пишет и спокойно меняет MAC.

Если тебе CAP что-то дал это значит «ядро разрешило». Потому что CAP - это ядро и есть.

CAP ядра дал привилегию, MAC ядра забрал привилегию и по итогу ядро запретит.

Если файловые CAP в системе работают, а MAC не используется, значит остался вариант с блокировкой привилегий процессу самим ядром.

Ядро Linux может некоторым процессам блокировать разрешенные CAP привилегии.

Например, если родительский процесс под root (init скрипты) он имеет привилегию выставлять своим дочерним процесам запрет на получения привилегий. Если запрет на получение привилегии cap_net_admin выставлен родительским процессом, то подсистема ядра CAP не сможет дать эту привилегию дочерному процессу.

Как и где в вашей системе инициализации это настроено не знаю.

Пример с командной строки:

# добавить в инит скрипт чтобы получить текущие привилегии
setpriv --dump --dump --dump 2>&1 >/tmp/debugpriv.dump

# запустить процесс без права иметь и получать привилегии
setpriv --inh-caps -all --ambient-caps -all --bounding-set -all --no-new-privs --securebits keep_caps_locked программа параметры

В Linux процесу можно дать, или отобрать у root, определенные привилегии и ЗАПРЕТИТЬ их получать этому процессу и его дочерным.

Если ваша система инициализации запустила qemu чем-то подобным на setpriv ... --no-new-privs --securebits keep_caps_locked ... qumu ..., то процесс не сможет получить дополнительные файловые CAP привилегии или стать root через s-бит.

ЗЫ: мое личное мнение, что аккуратная настройка привилегий setpriv и использование hardened chroot от grsecurity даст больше изоляции между процессом и системой чем любые контейнеры. Работать будет с большей скоростью. Кроме этого в chroot можно получить обновление софта с корневой системы.