Список мандатов¶

В следующим списке показаны мандаты, реализованные в Linux, а также операции или поведение, которые эти мандаты разрешают:

CAP_AUDIT_CONTROL (начиная с Linux 2.6.11)

Позволяет включать или выключать аудит ядра; изменять фильтрующие правила аудита; получать состояние аудита и фильтрующие правила.

CAP_AUDIT_READ (начиная с Linux 3.16)

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

CAP_AUDIT_WRITE (начиная с Linux 2.6.11)

Позволяет записывать данные в журнал аудита ядра.

CAP_BLOCK_SUSPEND (начиная с Linux 3.5)

Позволяет использовать возможности, которые могут приводить к блокированию приостановки системы (epoll(7) EPOLLWAKEUP, /proc/sys/wake_lock).

CAP_CHOWN

Позволяет выполнять произвольные изменения файловых UID и GID (смотрите chown(2)).

CAP_DAC_OVERRIDE

Позволяет пропускать проверки доступа к файлу на чтение, запись и выполнение (DAC (discretionary access control) — избирательный контроль доступа).

CAP_DAC_READ_SEARCH

CAP_FOWNER

CAP_FSETID

CAP_IPC_LOCK

Позволяет блокировать память (mlock(2), mlockall(2), mmap(2), shmctl(2)).

CAP_IPC_OWNER

Позволяет не выполнять проверки доступа для операций с объектами System V IPC.

CAP_KILL

Позволяет не выполнять проверки при отправке сигналов (смотрите kill(2)). Сюда относится использование ioctl(2) с операцией KDSIGACCEPT.

CAP_LEASE (начиная с Linux 2.4)

Позволяет устанавливать аренду на произвольные файлы (смотрите fcntl(2)).

CAP_LINUX_IMMUTABLE

Позволяет устанавливать флаги иноды FS_APPEND_FL и FS_IMMUTABLE_FL (смотрите ioctl_iflags(2)).

CAP_MAC_ADMIN (начиная с Linux 2.6.25)

Разрешает изменять настройку MAC или состояние. Реализован в Smack Linux Security Module (LSM).

CAP_MAC_OVERRIDE (начиная с Linux 2.6.25)

Позволяет замещать мандатный контроль доступа (MAC). Реализован в Smack LSM.

CAP_MKNOD (начиная с Linux 2.4)

Позволяет создавать специальные файлы с помощью mknod(2).

CAP_NET_ADMIN

Позволяет выполнять различные сетевые операции:

CAP_NET_BIND_SERVICE

Позволяет привязывать сокет к привилегированным портам домена интернета (номера портов меньше 1024).

CAP_NET_BROADCAST

(не используется) Позволяет осуществлять широковещание с сокета и прослушивание многоадресных рассылок.

CAP_NET_RAW

CAP_SETGID

CAP_SETFCAP (начиная с Linux 2.6.24)

Устанавливает произвольные мандаты на файл.

CAP_SETPCAP

Если файловые мандаты поддерживаются (т. е., начиная с Linux 2.6.24): позволяет добавлять любой мандат из ограничивающего набора вызывающей нити в её наследуемый набор; отзывать мандаты из ограничивающего набора (с помощью prctl(2) с операцией PR_CAPBSET_DROP); изменять флаги securebits.

Если файловые мандаты не поддерживаются (т. е., до Linux 2.6.24): позволяет предоставлять и отзывать любой мандат в списке разрешённых мандатов вызывающего или любого другого процесса (это свойство CAP_SETPCAP недоступно, если ядро собрано с поддержкой файловых мандатов, так как CAP_SETPCAP имеет полностью другую семантику у таких ядер).

CAP_SETUID

CAP_SYS_ADMIN

Замечание: данный мандат перегружен; смотрите Замечания разработчикам ядра ниже.

CAP_SYS_BOOT

Позволяет использовать reboot(2) и kexec_load(2).

CAP_SYS_CHROOT

Use chroot(2).

CAP_SYS_MODULE

CAP_SYS_NICE

CAP_SYS_PACCT

Позволяет использовать acct(2).

CAP_SYS_PTRACE

CAP_SYS_RAWIO

CAP_SYS_RESOURCE

CAP_SYS_TIME

Позволяет настраивать системные часы (settimeofday(2), stime(2), adjtimex(2)) и часы реального времени (аппаратные).

CAP_SYS_TTY_CONFIG

Позволяет использовать vhangup(2); задействовать различные привилегированные операции ioctl(2) с виртуальными терминалами.

CAP_SYSLOG (начиная с Linux 2.6.37)

CAP_WAKE_ALARM (начиная с Linux 3.0)

Позволяет вызывать что-либо при пробуждении системы (устанавливать таймеры CLOCK_REALTIME_ALARM и CLOCK_BOOTTIME_ALARM).

Старая и текущая реализации¶

Для полной реализации мандатов требуется:

1.

Для всех привилегированных операций ядро должно проверять, имеет ли нить требуемый мандат в его эффективном наборе.

2.

Ядро должно предоставлять системные вызовы, позволяющие получать и изменять наборы мандатов нити.

3.

Файловая система должна поддерживать присоединение мандатов к исполняемому файлу для того, чтобы при исполнении файла у процесса повышались права согласно этим мандатам.

До ядра версии 2.6.24 были реализованы только первые два пункта; начиная с версии 2.6.24 реализованы все три пункта.

Замечания разработчикам ядра¶

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

• Цель мандатов — разделить возможности суперпользователя на части, и если программа с одним или несколькими мандатами будет скомпрометирована, то её возможности нанести вред системе будут меньше, чем от такой же программы, выполняемой с правами суперпользователя.
• Вы можете создать новый мандат для новой возможности или привязать возможность к одному из существующих мандатов. Чтобы сохранить набор мандатов приемлемого размера, последний вариант предпочтителен, если нет неопровержимых доводов за первый вариант (есть также техническое ограничение: размер набора мандатов в настоящее время ограничен 64 битами).
• To determine which existing capability might best be associated with your new feature, review the list of capabilities above in order to find a "silo" into which your new feature best fits. One approach to take is to determine if there are other features requiring capabilities that will always be use along with the new feature. If the new feature is useless without these other features, you should use the same capability as the other features.
• Не используйте CAP_SYS_ADMIN, если этого можно избежать! С ним связана большая часть существующих проверок мандатов (смотрите часть списка выше). Его оправданно можно называть «новым суперпользователем», так как с одной стороны, он даёт широкий спектр полномочий, а с другой его широкий спектр действия означает, что данный мандат требуется многим привилегированным программам. Не делайте проблему хуже. Новые возможности, которые должны быть связаны с CAP_SYS_ADMIN должны сильно совпадать с существующими, использующими данное хранилище.
• Если действительно необходимо создать новый мандат для новой возможности, не делайте или называйте его как «только для этой возможности». То есть, например, добавление очень специализированного CAP_SYS_PACCT было бы, вероятно, ошибкой. Вместо этого попытайтесь идентифицировать и назвать новый мандат более вместительным понятием, в которое могут войти и другие будущие возможности.

Наборы мандатов нити¶

Each thread has three capability sets containing zero or more of the above capabilities:

Permitted:

Ограничивающий набор эффективных мандатов, которыми наделяется нить. Этот набор также ограничивает список мандатов, которые могут быть добавлены в наследуемый набор для нити, которая не имеет мандата CAP_SETPCAP в своём эффективном наборе.

Если нить сбрасывает мандат в своём разрешительном наборе, то она не сможет получить его назад (если только не выполняется execve(2) для программы с set-user-ID-root или программа, чьи соответствующие мандаты файла предоставляют этот мандат).

Inheritable:

Этот набор мандатов сохраняется при вызове execve(2). Наследуемые мандаты остаются наследуемыми при выполнении любой программы, и наследуемые мандаты добавляются в разрешительный набор, если выполняющаяся программа имеет соответствующие установленные биты в файловом наследуемом наборе.

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

Effective:

Данный набор мандатов используется ядром при выполнении проверок прав нити.

Ambient (since Linux 4.3):

Данный набор мандатов сохраняется после execve(2) для непривилегированных программ. Для набора наружных мандатов (ambient capability set) соблюдается правило, что ни один мандат не сможет быть наружным, если он одновременно разрешающий и наследуемый.

Набор наружных мандатов можно непосредственно изменять с помощью prctl(2). Наружные мандаты автоматически понижаются, если понижаются соответствующие разрешительные или наследуемые мандаты.

Executing a program that changes UID or GID due to the set-user-ID or set-group-ID bits or executing a program that has any file capabilities set will clear the ambient set. Ambient capabilities are added to the permitted set and assigned to the effective set when execve(2) is called.

Потомок, созданный fork(2), наследует копии наборов мандатов своего родителя. Далее смотрите описание отношения к мандатами при execve(2).

С помощью capset(2) нить может изменять свои наборы мандатов (смотрите далее).

Начиная с Linux 3.2, файл /proc/sys/kernel/cap_last_cap содержит числовое значение самого большого мандата, поддерживаемого работающим ядром; это может быть использовано для определения наибольшего бита, который может быть установлен в наборе мандатов.

Файловые мандаты¶

Начиная с ядра версии 2.6.24, с помощью setcap(8) поддерживается связь наборов мандатов с исполняемым файлом. Наборы мандатов файла хранятся в расширенном атрибуте (смотрите setxattr(2) и xattr(7)) с именем security.capability. Для записи в этот расширенный атрибут требуется мандат CAP_SETFCAP. Наборы файловых мандатов вместе с наборами мандатов нити определяют наборы мандатов нити после выполнения execve(2).

Три файловых набора мандатов:

Permitted (ранее называвшийся forced):

Эти мандаты автоматически разрешаются нити независимо от унаследованных мандатов нити.

Inheritable (ранее называвшийся allowed):

Этот набор объединяется (AND) с унаследованным набором нити для определения, какие унаследованные мандаты будут включены в разрешительный набор нити после execve(2).

Effective:

В действительности, это не набор, а одиночный бит. Если бит включён, то при вызове execve(2) все новые разрешённые мандаты нити будут также добавлены в эффективный набор. Если бит выключен, то после execve(2) ни один из новых разрешённых мандатов не будет добавлен в новый эффективный набор.

Включение эффективного файлового мандатного бита подразумевает, что любой файловый разрешительный или наследуемый мандат, который позволяет нити получить соответствующий разрешительный мандат при execve(2) (смотрите правила преобразования, описанные далее), также получит этот мандат в эффективном наборе. Поэтому, когда назначаются мандаты файлу (setcap(8), cap_set_file(3), cap_set_fd(3)), если мы укажем эффективный флаг как включённый для любого мандата, то эффективный флаг должен также быть указан включённым для всех остальных мандатов, для которых включён соответствующий разрешительный или наследуемый флаги.

File capability mask versioning¶

С целью расширяемости ядро поддерживает схему кодирования номера версии внутри расширенного атрибута security.capability, который используется в реализации файловых мандатов. Эти номера версий введены только для реализации и непосредственно не видны приложениям пользовательского пространства. В настоящее время поддерживаются следующие версии:

VFS_CAP_REVISION_1

Первоначальная реализация файловых мандатов, поддерживает 32-битные маски файловых мандатов.

VFS_CAP_REVISION_2 (начиная с Linux 2.6.25)

В данной версии поддерживаются 64-битные маски файловых мандатов, и и новый номер версии стал необходим для поддержки мандатов более 32. Ядро продолжает прозрачно поддерживать выполнение файлов с 32-битными масками мандатов 1-й версии, но при добавлении мандатов к файлам, у которых их ещё не было, или при изменение мандатов существующих файлов, оно автоматически использует схему 2-й версии (или, возможно, схему 3-ей версии как описано далее).

VFS_CAP_REVISION_3 (начиная с Linux 4.14)

Версия 3 файловые мандатов предоставляет поддержку файловых мандатов пространства имён (описано далее).

Как и в версии 2, версия 3 имеет 64-битную маску файловых мандатов. Но в дополнении, в расширенном атрибуте security.capability кодируется ID суперпользователя пространства имён (ID суперпользователя пространства имён — это значение, на которое отображается пользовательский ID 0 этого пространства имён в изначальном пользовательском пространстве имён).

Файловые мандаты версии 3 могут сосуществовать с мандатами версии 2; то есть в современной системе Linux одни файлы могут быть с мандатами версии 2, а другие с версией 3.

Before Linux 4.14, the only kind of capability mask that could be attached to a file was a VFS_CAP_REVISION_2 mask. Since Linux 4.14, the version of the capability mask that is attached to a file depends on the circumstances in which the security.capability extended attribute was created.

Начиная с Linux 4.14, расширенный атрибут security.capability автоматически создаётся (или преобразуется) как атрибут версии 3 (VFS_CAP_REVISION_3), если оба условия истинны:

(1)

The thread writing the attribute resides in a noninitial namespace. (More precisely: the thread resides in a user namespace other than the one from which the underlying filesystem was mounted.)

(2)

Нить имеет мандат CAP_SETFCAP поверх файловой иноды, то есть (a) нит имеет мандат CAP_SETFCAP в своём собственном пользовательском пространстве имён; и (b) UID и GID файловой иноды отображаются в пользовательское пространство имён записывающего.

При создании расширенного атрибута security.capability с типом VFS_CAP_REVISION_3 ID суперпользователя пользовательского пространства имён создающей нити сохраняется в расширенном атрибуте.

By contrast, creating a security.capability extended attribute from a privileged (CAP_SETFCAP) thread that resides in the namespace where the underlying filesystem was mounted (this normally means the initial user namespace) automatically results in a version 2 (VFS_CAP_REVISION_2) attribute.

Заметим, что файл может иметь расширенный атрибут security.capability версии 2 или версии 3, но не оба одновременно: создание или изменение расширенного атрибута security.capability автоматически приведёт к изменению версии согласно условиям, в которых он изменяется.

Преобразование мандатов при execve()¶

При execve(2) ядро вычисляет новые мандаты процесса по следующему алгоритму:

P'(ambient) =     (привилегированный файл) ? 0 : P(ambient)
P'(permitted)   = (P(inheritable) & F(inheritable)) |


                  (F(permitted) & cap_bset) | P'(ambient)
P'(effective) =   F(effective) ? P'(permitted) : P'(ambient)
P'(inheritable) = P(inheritable)    [т. е., не изменяется]

где:

A privileged file is one that has capabilities or has the set-user-ID or set-group-ID bit set.

Note: the capability transitions described above may not be performed (i.e., file capabilities may be ignored) for the same reasons that the set-user-ID and set-group-ID bits are ignored; see execve(2).

Замечание: в соответствии с правилами выше, если процесс ненулевым идентификатором пользователя выполняет execve(2), то все его мандаты в разрешительном и действующим наборах будут очищены. Учёт мандатов в случае, когда процесс имеет нулевой идентификатор пользователя и выполняет execve(2), описан далее в разделе Мандаты и выполнение программы с правами root.

Проверка на безопасность двоичных файлов, не отзывчивых к мандатам¶

Двоичный файл, не отзывчивый к мандатам (capability-dumb binary) — это приложение, которое помечено как имеющее файловые мандаты, но не преобразованное для работы с программным интерфейсом libcap(3) для управления своими мандатами (иначе говоря, это обычная set-user-ID-root программа, у которой указали файловые мандаты, но код которой не был изменён для понимания мандатов). У таких приложений на файле установлен эффективный файловый мандатный бит, из-за чего при исполнении файла у его процесса в эффективном наборе автоматически включаются разрешительные мандаты. Если ядро считает файл с установленным эффективным файловым мандатным битом не отзывчивым к мандатам, то выполняются проверки, описанные далее.

При запуске выполняемого файла, не отзывчивого к мандатам, ядро проверяет получил ли процесс все разрешительные мандаты, указанные в файловом разрешительном наборе, после преобразований мандатов, описанных выше (обычной причиной, почему это может не произойти, является то, что ограничивающий набор мандатов перекрывает некоторые мандаты из файлового разрешительного набора). Если процесс не получил полный набор файловых разрешительных мандатов, то execve(2) завершится с ошибкой EPERM. Это предотвращает возникновение проблем с безопасностью, которые могли бы появиться, если приложение, не отзывчивое к мандатам, выполняется с меньшими правами чем требуется. Заметим, что по определению само приложение не может увидеть эту проблему, так как не используется программный интерфейс libcap(3).

Мандаты и выполнение программ с правами root¶

In order to provide an all-powerful root using capability sets, during an execve(2):

1.

If a set-user-ID-root program is being executed, or the real or effective user ID of the process is 0 (root) then the file inheritable and permitted sets are defined to be all ones (i.e., all capabilities enabled).

2.

If a set-user-ID-root program is being executed, or the effective user ID of the process is 0 (root) then the file effective bit is defined to be one (enabled).

The upshot of the above rules, combined with the capabilities transformations described above, is as follows:

• When a process execve(2)s a set-user-ID-root program, or when a process with an effective UID of 0 execve(2)s a program, it gains all capabilities in its permitted and effective capability sets, except those masked out by the capability bounding set.
• When a process with a real UID of 0 execve(2)s a program, it gains all capabilities in its permitted capability set, except those masked out by the capability bounding set.

The above steps yield semantics that are the same as those provided by traditional UNIX systems.

Программы set-user-ID-root с файловыми мандатами¶

Executing a program that is both set-user-ID root and has file capabilities will cause the process to gain 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.

Ограничивающий набор мандатов¶

Ограничивающий набор мандатов — это механизм безопасности, который можно использовать для ограничения мандатов, которые могут быть получены при execve(2). Ограничивающий набор используется так:

• При execve(2) ограничивающий набор мандатов складывается (AND) с файловым разрешительным набором мандатов, и результат этой операции назначается разрешительному набору мандатов нити. Таким образом, ограничивающий набор мандатов ограничивает разрешённые мандаты, которые может предоставить исполняемый файл.
• (начиная с Linux 2.6.25) Ограничивающий набор мандатов служит ограничивающим набором мандатов, которые нить может добавить в свой наследуемый набор с помощью capset(2). Это означает, что если мандат отсутствует в ограничивающем наборе мандатов, то нить не может добавить этот мандат в свой наследуемый набор даже, если он есть в разрешительном наборе мандатов и поэтому не может сохранить данный мандат в разрешительный набор при вызове execve(2) для файла, который имеет мандат в своём наследуемом наборе.

Заметим, что ограничивающий набор скрывает файловые разрешительные мандаты, но не наследуемые мандаты. Если нить имеет мандат в своём наследуемом наборе, который отсутствует в ограничивающем наборе, то она по-прежнему обладает этим мандатом в своём разрешительном наборе при выполнении файла, который имеет мандат в своём наследуемом наборе.

В зависимости от версии ядра ограничивающий набор мандатов является либо системным свойством, либо атрибутом процесса.

Ограничивающий набор мандатов до Linux 2.6.25

В ядрах до версии 2.6.25 ограничивающий набор мандатов был системным атрибутом, который влиял на все нити системы. Ограничивающий набор доступен через файл /proc/sys/kernel/cap-bound (по непонятной причине, данный параметр, битовая маска, в /proc/sys/kernel/cap-bound записывался в виде знакового десятичного числа).

Только процесс init может задавать мандаты в ограничивающем наборе мандатов; помимо этого, суперпользователь (точнее, процесс с мандатом CAP_SYS_MODULE) может только удалять мандаты из набора.

В стандартной системе в ограничивающем наборе мандатов всегда удаляется мандат CAP_SETPCAP. Чтобы убрать это ограничение (опасно!), нужно изменить определение CAP_INIT_EFF_SET в include/linux/capability.h и пересобрать ядро.

Системное свойство, ограничивающий набор мандатов, было добавлено в ядро Linux версии 2.2.11.

Ограничивающий набор мандатов начиная с Linux 2.6.25

From Linux 2.6.25, the capability bounding set is a per-thread attribute. (There is no longer a system-wide capability bounding set.)

Ограничивающий набор наследуется при fork(2) от нити родителя и сохраняется при execve(2).

Нить может удалять мандаты из своего ограничивающего набора мандатов с помощью вызова prctl(2) с операцией PR_CAPBSET_DROP при наличии мандата CAP_SETPCAP. После удаления мандата из ограничивающего набора обратно его восстановить невозможно. Нить может определить наличие мандата в своём ограничивающем наборе с помощью вызова prctl(2) с операцией PR_CAPBSET_READ.

Удаление мандатов из ограничивающего набора доступно только, если ядро собрано с поддержкой файловых мандатов. В ядре Linux до версии 2.6.33 файловые мандаты являлись необязательным свойством, настраиваемым параметром CONFIG_SECURITY_FILE_CAPABILITIES. Начиная с Linux 2.6.33, параметр настройки был удалён и теперь файловые мандаты всегда являются частью ядра. Когда файловые мандаты в ядре, процесс init (предок всех процессов) запускается с полным ограничивающим набором. Если файловые мандаты не добавлены в ядро, то init запускается с полным ограничивающим набором минус CAP_SETPCAP, так как этот мандат имеет другое значение, если файловые мандаты отсутствуют.

Удаление мандата из ограничивающего набора не удаляет его из наследуемого набора нити. Однако это предотвращает от добавления мандата обратно в наследуемый набор нити в будущем.

Влияние изменения пользовательского ID на мандаты¶

Для сохранения привычной семантики при переходе от 0 к ненулевым пользовательским ID, ядро делает следующие изменения наборов мандатов нити при изменении у нити реального, эффективного, сохранённого ID и пользовательского ID файловой системы (с помощью setuid(2), setresuid(2) или подобных):

1.

Если ранее реальный, эффективный или сохранённый пользовательский ID не был равен 0, и в результате изменения UID все эти ID получили ненулевое значение, то все мандаты удаляются из разрешительного, эффективного, и наружного набора мандатов.

2.

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

3.

Если эффективный пользовательский ID изменяется с ненулевого значения на 0, то разрешительный набор копируется в эффективный набор.

4.

Если пользовательский ID файловой системы изменяется с 0 на ненулевое значение (смотрите setfsuid(2)), то следующие мандаты удаляются из эффективного набора: CAP_CHOWN, CAP_DAC_OVERRIDE, CAP_DAC_READ_SEARCH, CAP_FOWNER, CAP_FSETID, CAP_LINUX_IMMUTABLE (начиная с Linux 2.6.30), CAP_MAC_OVERRIDE и CAP_MKNOD (начиная с Linux 2.6.30). Если пользовательский ID файловой системы изменяется с ненулевого значения на 0, то любой из мандатов, включённых в разрешительный набор, включается в эффективном наборе.

Если нить, у которой один или более пользовательских ID равно 0, хочет предотвратить удаление разрешительных мандатов при сбросе всех пользовательских ID в ненулевые значения, то она может использовать флаг SECBIT_KEEP_CAPS в securebits, описанный далее.

Программное изменение наборов мандатов¶

A thread can retrieve and change its capability sets using the capget(2) and capset(2) system calls. However, the use of cap_get_proc(3) and cap_set_proc(3), both provided in the libcap package, is preferred for this purpose. The following rules govern changes to the thread capability sets:

1.

Если вызывающий не имеет мандата CAP_SETPCAP, то новый наследуемый набор должен быть поднабором комбинации существующего наследуемого и разрешительного наборов.

2.

(начиная с Linux 2.6.25) Новый наследуемый набор должен быть поднабором комбинации существующего наследуемого и ограничивающего наборов.

3.

Новый разрешительный набор должен быть поднабором существующего разрешительного набора (т. е., невозможно приобрести разрешительные мандаты, которых нить не имеет).

4.

Новый эффективный набор должен быть поднабором нового разрешительного набора.

Флаги securebits: организация исключительно мандатного окружения¶

Начиная с ядра версии 2.6.26 с включённой поддержкой файловых мандатов, в Linux реализован набор флагов securebits (для каждой нити), который можно использовать для отключения специальных действий мандатов для UID 0 (root). К этим флагам относятся:

SECBIT_KEEP_CAPS

Setting this flag allows a thread that has one or more 0 UIDs to retain capabilities in its permitted and effective sets when it switches all of its UIDs to nonzero values. If this flag is not set, then such a UID switch causes the thread to lose all capabilities in those sets. This flag is always cleared on an execve(2).

Установка флага SECBIT_KEEP_CAPS игнорируется, если указан флаг SECBIT_NO_SETUID_FIXUP (этот флаг предоставляет надмножество свойств первого флага).

Этот флаг предоставляет возможности старой операции PR_SET_KEEPCAPS вызова prctl(2).

SECBIT_NO_SETUID_FIXUP

Установка этого флага не даёт ядру изменить разрешительный, эффективный и наружный набор мандатов при изменении эффективного UID и UID файловой системы нити с 0 на ненулевое значение (смотрите раздел Влияние изменения пользовательского ID на мандаты).

SECBIT_NOROOT

Если этот бит установлен, то ядро не предоставляет мандаты при исполнении программы, имеющей бит set-user-ID-root, или когда процесс с эффективным или реальным UID равным 0 вызывает execve(2) (смотрите раздел Мандаты и выполнение программа от root).

SECBIT_NO_CAP_AMBIENT_RAISE

Установка этого флага запрещает повышение наружных мандатов посредством prctl(2)с операцией PR_CAP_AMBIENT_RAISE.

Каждый из перечисленных выше «базовых» флагов имеет дополнительный флаг «блокировки». Установка любого из флагов «блокировки» необратима и запрещает дальнейшие изменения соответствующего «базового» флага. Флаги блокировки: SECBIT_KEEP_CAPS_LOCKED, SECBIT_NO_SETUID_FIXUP_LOCKED, SECBIT_NOROOT_LOCKED и SECBIT_NO_CAP_AMBIENT_RAISE_LOCKED.

The securebits flags can be modified and retrieved using the prctl(2) PR_SET_SECUREBITS and PR_GET_SECUREBITS operations. The CAP_SETPCAP capability is required to modify the flags.

Флаги securebits наследуются дочерними процессами. При execve(2) все флаги сохраняются, за исключением SECBIT_KEEP_CAPS, который всегда сбрасывается.

Приложение может использовать следующий вызов для собственной блокировки и помещение всех своих потомков в окружение, в котором есть только один способ добавить права — запустить программу со связанными с ней файловыми мандатами:

prctl(PR_SET_SECUREBITS,
	/* SECBIT_KEEP_CAPS off */


        SECBIT_KEEP_CAPS_LOCKED |


        SECBIT_NO_SETUID_FIXUP |


        SECBIT_NO_SETUID_FIXUP_LOCKED |


        SECBIT_NOROOT |


        SECBIT_NOROOT_LOCKED);


        /* Setting/locking SECBIT_NO_CAP_AMBIENT_RAISE


           is not required */

Взаимодействие с пользовательскими пространствами имён¶

For a discussion of the interaction of capabilities and user namespaces, see user_namespaces(7).

Файловые мандаты пространства имён¶

Обычные (т. е., с версией 2) файловые мандаты представляют собой только связь набора мандатных масок и двоичного исполняемого файла. Когда процесс выполняет двоичный файл с такими мандатами он получает присоединённые мандаты (внутри своего пользовательского пространства имён) согласно правилам, описанным выше в «Преобразование мандатов при execve()».

Так как файловые мандаты версии 2 предоставляются выполняющемуся процессу независимо от того, в каком пользовательском пространстве имён он располагается, то только привилегированным процессам разрешено связывать мандаты с файлом. Здесь «привилегированным» считается процесс, имеющий мандат CAP_SETFCAP в пользовательском пространстве имён, в котором была смонтирована файловая система (обычно, изначальное пользовательское пространство имён). Это ограничение в определённых случаях делает файловые мандаты бесполезными. Например, в контейнерах пользовательских пространств имён может требоваться возможность создания двоичных файлов, которые предоставляют мандаты только процессам, выполняемым внутри контейнера, но не процессам, выполняемым вне контейнера.

Linux 4.14 added so-called namespaced file capabilities to support such use cases. Namespaced file capabilities are recorded as version 3 (i.e., VFS_CAP_REVISION_3) security.capability extended attributes. Such an attribute is automatically created when a process that resides in a noninitial user namespace associates (setxattr(2)) file capabilities with a file whose user ID matches the user ID of the creator of the namespace. In this case, the kernel records not just the capability masks in the extended attribute, but also the namespace root user ID. For further details, see File capability mask versioning, above.

As with a binary that has VFS_CAP_REVISION_2 file capabilities, a binary with VFS_CAP_REVISION_3 file capabilities confers capabilities to a process during execve(). However, capabilities are conferred only if the binary is executed by a process that resides in a user namespace whose UID 0 maps to the root user ID that is saved in the extended attribute, or when executed by a process that resides in descendant of such a namespace.