capabilities - root по кусочкам

Оригинал https://t.me/bits_and_bicycles/14

Что-то мне подсказывает, uid 0 был выбран для суперпользователя по банальной причине: удобно писать if (uid && !allowed(uid, ...)) goto fail;.

Со временем пришло осознание, что во множестве ситуаций нужен не весь root, а только кусочек. Ну странно же давать право менять модули ядра nginx'у, которому всего-то надо забиндить 80й порт.

В итоге, права суперпользователя нарезали на capabilities. В 6.1.3 их целых 43 штуки. Например, можно запретить всё и выдать только разрешения биндить 0-1023 порты CAP_NET_BIND_SERVICE и посылать raw-пакеты CAP_NET_RAW. Или выдать разрешение выдавать разрешения CAP_SETPCAP.

capabilities, так же как и uid, – атрибут не пользователя, а процесса (на самом деле треда, но не важно). Напоминаю, пользователей не существует. Раньше у процесса был только атрибут-число uid, теперь к нему добавился атрибут-битсет capabilities. При этом capabilities и uid никак не связаны. У тебя может быть всемогущий uid 1337 и никчёмный uid 0.

Посмотреть этот битсет можно в #procfs

$ grep '^Cap' /proc/self/status
CapInh: 10000000a80425fb
CapPrm: 20000000a80425fb
CapEff: 30000000a80425fb
CapBnd: 40000000a80425fb
CapAmb: 5000000000000000

Работать с привелегиями можно через пару syscall'ов capset и prctl. Привелегии можно повышать, понижать, понижать временно, настраивать наследование дочерними процессами.

Также для повышения привилегий есть механизм setcap на файле, аналогичный suid биту. Но это если файловая система поддерживает атрибуты у файлов, если ты ретроград с ext1, то остаётся только ~пить галоперидол~ получать классический root.