.\" -*- coding: UTF-8 -*- .\" Copyright (c) 2002 by Michael Kerrisk .\" .\" SPDX-License-Identifier: Linux-man-pages-copyleft .\" .\" 6 Aug 2002 - Initial Creation .\" Modified 2003-05-23, Michael Kerrisk, .\" Modified 2004-05-27, Michael Kerrisk, .\" 2004-12-08, mtk Added O_NOATIME for CAP_FOWNER .\" 2005-08-16, mtk, Added CAP_AUDIT_CONTROL and CAP_AUDIT_WRITE .\" 2008-07-15, Serge Hallyn .\" Document file capabilities, per-process capability .\" bounding set, changed semantics for CAP_SETPCAP, .\" and other changes in Linux 2.6.2[45]. .\" Add CAP_MAC_ADMIN, CAP_MAC_OVERRIDE, CAP_SETFCAP. .\" 2008-07-15, mtk .\" Add text describing circumstances in which CAP_SETPCAP .\" (theoretically) permits a thread to change the .\" capability sets of another thread. .\" Add section describing rules for programmatically .\" adjusting thread capability sets. .\" Describe rationale for capability bounding set. .\" Document "securebits" flags. .\" Add text noting that if we set the effective flag for one file .\" capability, then we must also set the effective flag for all .\" other capabilities where the permitted or inheritable bit is set. .\" 2011-09-07, mtk/Serge hallyn: Add CAP_SYSLOG .\" .\"******************************************************************* .\" .\" This file was generated with po4a. Translate the source file. .\" .\"******************************************************************* .TH Мандаты 7 "3 мая 2023 г." "Linux man\-pages 6.05.01" .SH ИМЯ capabilities \- обзор мандатов Linux .SH ОПИСАНИЕ Для выполнения проверки прав доступа в обычных реализациях UNIX процессы разделяют на две категории: \fIпривилегированные\fP (ID эффективного пользователя равен 0, как у суперпользователя или root), и \fIне привилегированные\fP (ID эффективного пользователя не равен нулю). Для привилегированных процессов все проверки прав в ядре не выполняются, а для не привилегированных процессов выполняется полная проверка на основе мандатов процесса (обычно, эффективного UID, эффективного GID и списка дополнительных групп). .PP .\" Starting with Linux 2.2, Linux divides the privileges traditionally associated with superuser into distinct units, known as \fIcapabilities\fP, which can be independently enabled and disabled. Capabilities are a per\-thread attribute. .SS "Список мандатов" В следующим списке показаны мандаты, реализованные в Linux, а также операции или поведение, которые эти мандаты разрешают: .TP \fBCAP_AUDIT_CONTROL\fP (начиная с Linux 2.6.11) Позволяет включать или выключать аудит ядра; изменять фильтрующие правила аудита; получать состояние аудита и фильтрующие правила. .TP \fBCAP_AUDIT_READ\fP (начиная с Linux 3.16) .\" commit a29b694aa1739f9d76538e34ae25524f9c549d59 .\" commit 3a101b8de0d39403b2c7e5c23fd0b005668acf48 Позволяет читать протокол аудита через многоадресный сокет netlink. .TP \fBCAP_AUDIT_WRITE\fP (начиная с Linux 2.6.11) .\" FIXME Add FAN_ENABLE_AUDIT Позволяет записывать данные в журнал аудита ядра. .TP \fBCAP_BLOCK_SUSPEND\fP (начиная с Linux 3.5) Позволяет использовать возможности, которые могут приводить к блокированию приостановки системы (\fBepoll\fP(7) \fBEPOLLWAKEUP\fP, \fI/proc/sys/wake_lock\fP). .TP \fBCAP_BPF\fP (since Linux 5.8) Employ privileged BPF operations; see \fBbpf\fP(2) and \fBbpf\-helpers\fP(7). .IP This capability was added in Linux 5.8 to separate out BPF functionality from the overloaded \fBCAP_SYS_ADMIN\fP capability. .TP \fBCAP_CHECKPOINT_RESTORE\fP (since Linux 5.9) .\" commit 124ea650d3072b005457faed69909221c2905a1f .PD 0 .RS .IP \[bu] 3 Update \fI/proc/sys/kernel/ns_last_pid\fP (see \fBpid_namespaces\fP(7)); .IP \[bu] .\" FIXME There is also some use case relating to .\" prctl_set_mm_exe_file(); in the 5.9 sources, see .\" prctl_set_mm_map(). employ the \fIset_tid\fP feature of \fBclone3\fP(2); .IP \[bu] read the contents of the symbolic links in \fI/proc/\fPpid\fI/map_files\fP for other processes. .RE .PD .IP This capability was added in Linux 5.9 to separate out checkpoint/restore functionality from the overloaded \fBCAP_SYS_ADMIN\fP capability. .TP \fBCAP_CHOWN\fP Позволяет выполнять произвольные изменения файловых UID и GID (смотрите \fBchown\fP(2)). .TP \fBCAP_DAC_OVERRIDE\fP Позволяет пропускать проверки доступа к файлу на чтение, запись и выполнение (DAC (discretionary access control) — избирательный контроль доступа). .TP \fBCAP_DAC_READ_SEARCH\fP .PD 0 .RS .IP \[bu] 3 Позволяет пропускать проверки доступа к файлу на чтение и доступа к каталогу на чтение и выполнение; .IP \[bu] Позволяет вызывать \fBopen_by_handle_at\fP(2); .IP \[bu] Позволяет использовать \fBlinkat\fP(2) с флагом \fBAT_EMPTY_PATH\fP для создания ссылки на файл, заданным файловым дескриптором. .RE .PD .TP \fBCAP_FOWNER\fP .PD 0 .RS .IP \[bu] 3 Позволяет пропускать проверки доступа для операций, которые обычно требуют совпадения UID файловой системы процесса и UID файла (например, \fBchmod\fP(2), \fButime\fP(2)), исключая операции, охватываемые \fBCAP_DAC_OVERRIDE\fP и \fBCAP_DAC_READ_SEARCH\fP; .IP \[bu] Позволяет изменять флаги иноды (смотрите \fBioctl_iflags\fP(2)) у произвольных файлов; .IP \[bu] Позволяет устанавливать списки контроля доступа (ACL) произвольных файлов; .IP \[bu] Позволяет игнорировать закрепляющий бит при удалении файла; .IP \[bu] Позволяет изменять расширенные \fIпользовательские\fP атрибуты закреплённого каталога, принадлежащего любому пользователю; .IP \[bu] Позволяет задавать \fBO_NOATIME\fP для произвольных файлов в \fBopen\fP(2) и \fBfcntl\fP(2). .RE .PD .TP \fBCAP_FSETID\fP .PD 0 .RS .IP \[bu] 3 Позволяет не очищать биты режима set\-user\-ID и set\-group\-ID при изменении файла; .IP \[bu] Позволяет устанавливать бит set\-group\-ID на файл, у которого GID не совпадает с битом файловой системы или любыми дополнительными GID вызывающего процесса. .RE .PD .TP \fBCAP_IPC_LOCK\fP .\" FIXME . As at Linux 3.2, there are some strange uses of this capability .\" in other places; they probably should be replaced with something else. .PD 0 .RS .IP \[bu] 3 Lock memory (\fBmlock\fP(2), \fBmlockall\fP(2), \fBmmap\fP(2), \fBshmctl\fP(2)); .IP \[bu] Allocate memory using huge pages (\fBmemfd_create\fP(2), \fBmmap\fP(2), \fBshmctl\fP(2)). .RE .PD .TP \fBCAP_IPC_OWNER\fP Позволяет не выполнять проверки доступа для операций с объектами System V IPC. .TP \fBCAP_KILL\fP .\" FIXME . CAP_KILL also has an effect for threads + setting child .\" termination signal to other than SIGCHLD: without this .\" capability, the termination signal reverts to SIGCHLD .\" if the child does an exec(). What is the rationale .\" for this? Позволяет не выполнять проверки при отправке сигналов (смотрите \fBkill\fP(2)). Сюда относится использование \fBioctl\fP(2) с операцией \fBKDSIGACCEPT\fP. .TP \fBCAP_LEASE\fP (начиная с Linux 2.4) Позволяет устанавливать аренду на произвольные файлы (смотрите \fBfcntl\fP(2)). .TP \fBCAP_LINUX_IMMUTABLE\fP Позволяет устанавливать флаги иноды \fBFS_APPEND_FL\fP и \fBFS_IMMUTABLE_FL\fP (смотрите \fBioctl_iflags\fP(2)). .TP \fBCAP_MAC_ADMIN\fP (начиная с Linux 2.6.25) Разрешает изменять настройку MAC или состояние. Реализован в Smack Linux Security Module (LSM). .TP \fBCAP_MAC_OVERRIDE\fP (начиная с Linux 2.6.25) Позволяет замещать мандатный контроль доступа (MAC). Реализован в Smack LSM. .TP \fBCAP_MKNOD\fP (начиная с Linux 2.4) Позволяет создавать специальные файлы с помощью \fBmknod\fP(2). .TP \fBCAP_NET_ADMIN\fP Позволяет выполнять различные сетевые операции: .PD 0 .RS .IP \[bu] 3 настройку интерфейса; .IP \[bu] управление IP МЭ, трансляцией адресов и ведением учёта; .IP \[bu] изменять таблицы маршрутизации; .IP \[bu] привязываться к любому адресу для прозрачного проксирования; .IP \[bu] set type\-of\-service (TOS); .IP \[bu] очищать статистику драйвера; .IP \[bu] включать режим захвата (promiscuous); .IP \[bu] включать многоадресные рассылки (multicasting); .IP \[bu] использовать \fBsetsockopt\fP(2) для включения следующих параметров сокета: \fBSO_DEBUG\fP, \fBSO_MARK\fP, \fBSO_PRIORITY\fP (для приоритетов вне диапазона 0 \- 6), \fBSO_RCVBUFFORCE\fP и \fBSO_SNDBUFFORCE\fP. .RE .PD .TP \fBCAP_NET_BIND_SERVICE\fP Позволяет привязывать сокет к привилегированным портам домена интернета (номера портов меньше 1024). .TP \fBCAP_NET_BROADCAST\fP .\" FIXME Since Linux 4.2, there are use cases for netlink sockets .\" commit 59324cf35aba5336b611074028777838a963d03b (не используется) Позволяет осуществлять широковещание с сокета и прослушивание многоадресных рассылок. .TP \fBCAP_NET_RAW\fP .PD 0 .RS .IP \[bu] 3 Позволяет использовать сокеты RAW и PACKET; .IP \[bu] позволяет привязываться к любому адресу для прозрачного проксирования. .RE .PD .\" Also various IP options and setsockopt(SO_BINDTODEVICE) .TP \fBCAP_PERFMON\fP (since Linux 5.8) Employ various performance\-monitoring mechanisms, including: .RS .IP \[bu] 3 .PD 0 Позволяет вызывать \fBperf_event_open\fP(2); .IP \[bu] employ various BPF operations that have performance implications. .RE .PD .IP This capability was added in Linux 5.8 to separate out performance monitoring functionality from the overloaded \fBCAP_SYS_ADMIN\fP capability. See also the kernel source file \fIDocumentation/admin\-guide/perf\-security.rst\fP. .TP \fBCAP_SETGID\fP .RS .PD 0 .IP \[bu] 3 Позволяет выполнять произвольные действия с GID процесса и списком дополнительных GID; .IP \[bu] Позволяет подделывать GID при передаче мандатов сокета через доменные сокеты UNIX; .IP \[bu] Позволяет записывать отображение идентификатора группы в пользовательское пространство (смотрите \fBuser_namespaces\fP(7)). .PD .RE .TP \fBCAP_SETFCAP\fP (начиная с Linux 2.6.24) Устанавливает произвольные мандаты на файл. .IP .\" commit db2e718a47984b9d71ed890eb2ea36ecf150de18 Since Linux 5.12, this capability is also needed to map user ID 0 in a new user namespace; see \fBuser_namespaces\fP(7) for details. .TP \fBCAP_SETPCAP\fP Если файловые мандаты поддерживаются (т. е., начиная с Linux 2.6.24): позволяет добавлять любой мандат из ограничивающего набора вызывающей нити в её наследуемый набор; отзывать мандаты из ограничивающего набора (с помощью \fBprctl\fP(2) с операцией \fBPR_CAPBSET_DROP\fP); изменять флаги \fIsecurebits\fP. .IP If file capabilities are not supported (i.e., before Linux 2.6.24): grant or remove any capability in the caller's permitted capability set to or from any other process. (This property of \fBCAP_SETPCAP\fP is not available when the kernel is configured to support file capabilities, since \fBCAP_SETPCAP\fP has entirely different semantics for such kernels.) .TP \fBCAP_SETUID\fP .RS .PD 0 .IP \[bu] 3 Позволяет выполнять произвольные действия с UID процесса (\fBsetuid\fP(2), \fBsetreuid\fP(2), \fBsetresuid\fP(2), \fBsetfsuid\fP(2)); .IP \[bu] Позволяет подделывать UID при передаче мандатов сокета через доменные сокеты UNIX; .IP \[bu] Позволяет записывать отображение идентификатора пользователя в пользовательское пространство (смотрите \fBuser_namespaces\fP(7)). .PD .RE .\" FIXME CAP_SETUID also an effect in exec(); document this. .TP \fBCAP_SYS_ADMIN\fP \fINote\fP: this capability is overloaded; see \fINotes to kernel developers\fP below. .IP .PD 0 .RS .IP \[bu] 3 Позволяет выполнять следующие задачи управления системой: \fBquotactl\fP(2), \fBmount\fP(2), \fBumount\fP(2), \fBpivot_root\fP(2), \fBswapon\fP(2), \fBswapoff\fP(2), \fBsethostname\fP(2), and \fBsetdomainname\fP(2); .IP \[bu] Позволяет выполнять привилегированные операции \fBsyslog\fP(2) (начиная с Linux 2.6.37, для этих операций нужно использовать \fBCAP_SYSLOG\fP); .IP \[bu] Позволяет выполнять команду \fBVM86_REQUEST_IRQ\fP \fBvm86\fP(2); .IP \[bu] access the same checkpoint/restore functionality that is governed by \fBCAP_CHECKPOINT_RESTORE\fP (but the latter, weaker capability is preferred for accessing that functionality). .IP \[bu] perform the same BPF operations as are governed by \fBCAP_BPF\fP (but the latter, weaker capability is preferred for accessing that functionality). .IP \[bu] employ the same performance monitoring mechanisms as are governed by \fBCAP_PERFMON\fP (but the latter, weaker capability is preferred for accessing that functionality). .IP \[bu] Позволяет выполнять операции \fBIPC_SET\fP и \fBIPC_RMID\fP над произвольными объектами System V IPC; .IP \[bu] Позволяет перезаписывать ограничение ресурса \fBRLIMIT_NPROC\fP; .IP \[bu] perform operations on \fItrusted\fP and \fIsecurity\fP extended attributes (see \fBxattr\fP(7)); .IP \[bu] Позволяет использовать \fBlookup_dcookie\fP(2); .IP \[bu] Позволяет использовать \fBioprio_set\fP(2) для назначения классов планирования ввода\-вывода \fBIOPRIO_CLASS_RT\fP и (до Linux 2.6.25) \fBIOPRIO_CLASS_IDLE\fP; .IP \[bu] Позволяет подделывать PID при передаче мандатов сокета через доменные сокеты UNIX; .IP \[bu] Позволяет превышать \fI/proc/sys/fs/file\-max\fP, системное ограничение на количество открытых файлов, в системных вызовах, открывающих файлы (например, \fBaccept\fP(2), \fBexecve\fP(2), \fBopen\fP(2), \fBpipe\fP(2)); .IP \[bu] Позволяет задействовать флаги \fBCLONE_*\fP, которые создают новые пространства имён с помощью \fBclone\fP(2) и \fBunshare\fP(2)) (начиная с Linux 3.8 для создания пользовательских пространств имён больше никаких мандатов не требуется); .IP \[bu] Позволяет получать доступ к информации о привилегированном событии \fIperf\fP; .IP \[bu] Позволяет вызывать \fBsetns\fP(2) (требуется \fBCAP_SYS_ADMIN\fP в пространстве имён \fIназначения\fP); .IP \[bu] Позволяет вызывать \fBfanotify_init\fP(2); .IP \[bu] Позволяет выполнять привилегированные операции \fBKEYCTL_CHOWN\fP и \fBKEYCTL_SETPERM\fP в \fBkeyctl\fP(2); .IP \[bu] Позволяет выполнять операцию \fBMADV_HWPOISON\fP в \fBmadvise\fP(2); .IP \[bu] Позволяет задействовать \fBTIOCSTI\fP в \fBioctl\fP(2) для вставки символов во входную очередь терминала, отличного от управляющего терминала вызывающего; .IP \[bu] Позволяет задействовать устаревший системный вызов \fBnfsservctl\fP(2); .IP \[bu] Позволяет задействовать устаревший системный вызов \fBbdflush\fP(2); .IP \[bu] Позволяет выполнять различные привилегированные операции \fBioctl\fP(2) над блочными устройствами; .IP \[bu] Позволяет выполнять различные привилегированные операции \fBioctl\fP(2) над файловой системой; .IP \[bu] Позволяет выполнять привилегированные операции \fBioctl\fP(2) над устройством \fI/dev/random\fP (смотрите \fBrandom\fP(4)); .IP \[bu] Позволяет устанавливать фильтры \fBseccomp\fP(2) без начальной установки атрибута нити \fIno_new_privs\fP; .IP \[bu] Позволяет изменять правила разрешения/запрета для групп управления устройствами; .IP \[bu] Позволяет задействовать операцию \fBptrace\fP(2) \fBPTRACE_SECCOMP_GET_FILTER\fP для получения дампа фильтров seccomp трассируемого; .IP \[bu] Позволяет задействовать операцию \fBptrace\fP(2) \fBPTRACE_SETOPTIONS\fP для приостановки защиты seccomp трассируемого (т. е., флаг \fBPTRACE_O_SUSPEND_SECCOMP\fP); .IP \[bu] perform administrative operations on many device drivers; .IP \[bu] modify autogroup nice values by writing to \fI/proc/\fPpid\fI/autogroup\fP (see \fBsched\fP(7)). .RE .PD .TP \fBCAP_SYS_BOOT\fP Позволяет использовать \fBreboot\fP(2) и \fBkexec_load\fP(2). .TP \fBCAP_SYS_CHROOT\fP .RS .PD 0 .IP \[bu] 3 Позволяет использовать \fBchroot\fP(2); .IP \[bu] Позволяет изменять пространство имён монтирования с помощью \fBsetns\fP(2). .PD .RE .TP \fBCAP_SYS_MODULE\fP .RS .PD 0 .IP \[bu] 3 Позволяет загружать и выгружать модули ядра (смотрите \fBinit_module\fP(2) и \fBdelete_module\fP(2)); .IP \[bu] before Linux 2.6.25: drop capabilities from the system\-wide capability bounding set. .PD .RE .TP \fBCAP_SYS_NICE\fP .PD 0 .RS .IP \[bu] 3 Lower the process nice value (\fBnice\fP(2), \fBsetpriority\fP(2)) and change the nice value for arbitrary processes; .IP \[bu] Позволяет назначать политики планирования реального времени для вызывающего процесса и назначать политики планирования и приоритеты для произвольных процессов (\fBsched_setscheduler\fP(2), \fBsched_setparam\fP(2), \fBsched_setattr\fP(2)); .IP \[bu] Позволяет выполнять привязку к ЦП для произвольных процессов (\fBsched_setaffinity\fP(2)); .IP \[bu] Позволяет назначать класс планирования ввода\-вывода и приоритет для произвольных процессов (\fBioprio_set\fP(2)); .IP \[bu] .\" FIXME CAP_SYS_NICE also has the following effect for .\" migrate_pages(2): .\" do_migrate_pages(mm, &old, &new, .\" capable(CAP_SYS_NICE) ? MPOL_MF_MOVE_ALL : MPOL_MF_MOVE); .\" .\" Document this. Позволяет применять \fBmigrate_pages\fP(2) к произвольным процессам для их перемещения на произвольные узлы; .IP \[bu] Позволяет применять \fBmove_pages\fP(2) к произвольным процессам; .IP \[bu] Позволяет использовать флаг \fBMPOL_MF_MOVE_ALL\fP в \fBmbind\fP(2) и \fBmove_pages\fP(2). .RE .PD .TP \fBCAP_SYS_PACCT\fP Позволяет использовать \fBacct\fP(2). .TP \fBCAP_SYS_PTRACE\fP .PD 0 .RS .IP \[bu] 3 Позволяет трассировать любой процесс с помощью \fBptrace\fP(2); .IP \[bu] Позволяет применять \fBget_robust_list\fP(2) к произвольным процессам; .IP \[bu] Позволяет перемещать данные в/из памяти произвольного процесса с помощью \fBprocess_vm_readv\fP(2) и \fBprocess_vm_writev\fP(2); .IP \[bu] Позволяет изучать процессы с помощью \fBkcmp\fP(2). .RE .PD .TP \fBCAP_SYS_RAWIO\fP .PD 0 .RS .IP \[bu] 3 Позволяет выполнять операции ввода\-вывода из портов (\fBiopl\fP(2) и \fBioperm\fP(2)); .IP \[bu] Разрешает доступ к \fI/proc/kcore\fP; .IP \[bu] Позволяет задействовать операцию \fBFIBMAP\fP в \fBioctl\fP(2); .IP \[bu] Позволяет открывать устройства для доступа к специальным регистрам x86 (MSR, смотрите \fBmsr\fP(4)); .IP \[bu] Позволяет обновлять \fI/proc/sys/vm/mmap_min_addr\fP; .IP \[bu] Позволяет создавать отображения памяти по адресам меньше значения, заданного в \fI/proc/sys/vm/mmap_min_addr\fP; .IP \[bu] Позволяет отображать файлы в \fI/proc/bus/pci\fP; .IP \[bu] Позволяет открывать \fI/dev/mem\fP и \fI/dev/kmem\fP; .IP \[bu] Позволяет выполнять различные команды устройств SCSI; .IP \[bu] Позволяет выполнять определённые операции с устройствами \fBhpsa\fP(4) и \fBcciss\fP(4); .IP \[bu] Позволяет выполнять некоторые специальные операции с другими устройствами. .RE .PD .TP \fBCAP_SYS_RESOURCE\fP .PD 0 .RS .IP \[bu] 3 Позволяет использовать зарезервированное пространство файловых систем ext2; .IP \[bu] Позволяет делать вызовы \fBioctl\fP(2), управляющие журналированием ext3; .IP \[bu] Позволяет превышать ограничение дисковой квоты; .IP \[bu] Позволяет увеличивать ограничения по ресурсам (смотрите \fBsetrlimit\fP(2)); .IP \[bu] Позволяет перезаписывать ограничение ресурса \fBRLIMIT_NPROC\fP; .IP \[bu] Позволяет превышать максимальное количество консолей при выделении консоли; .IP \[bu] Позволяет превышать максимальное количество раскладок; .IP \[bu] Позволяет использовать более чем 64hz прерывания из часов реального времени; .IP \[bu] Позволяет назначать значение \fImsg_qbytes\fP очереди сообщений System V больше ограничения \fI/proc/sys/kernel/msgmnb\fP (смотрите \fBmsgop\fP(2) и \fBmsgctl\fP(2)); .IP \[bu] Позволяет обходить ограничитель ресурса \fBRLIMIT_NOFILE\fP для файловых дескрипторов, находящихся в процессе передачи («в полёте», in\-flight), когда файловые дескрипторы передаются в другой процесс через доменный сокет UNIX (смотрите \fBunix\fP(7)); .IP \[bu] override the \fI/proc/sys/fs/pipe\-size\-max\fP limit when setting the capacity of a pipe using the \fBF_SETPIPE_SZ\fP \fBfcntl\fP(2) command; .IP \[bu] Позволяет использовать \fBF_SETPIPE_SZ\fP для увеличения вместимости канала больше чем ограничение, задаваемое в \fI/proc/sys/fs/pipe\-max\-size\fP; .IP \[bu] override \fI/proc/sys/fs/mqueue/queues_max\fP, \fI/proc/sys/fs/mqueue/msg_max\fP, and \fI/proc/sys/fs/mqueue/msgsize_max\fP limits when creating POSIX message queues (see \fBmq_overview\fP(7)); .IP \[bu] Позволяет задействовать операцию \fBprctl\fP(2) \fBPR_SET_MM\fP(); .IP \[bu] set \fI/proc/\fPpid\fI/oom_score_adj\fP to a value lower than the value last set by a process with \fBCAP_SYS_RESOURCE\fP. .RE .PD .TP \fBCAP_SYS_TIME\fP Позволяет настраивать системные часы (\fBsettimeofday\fP(2), \fBstime\fP(2), \fBadjtimex\fP(2)) и часы реального времени (аппаратные). .TP \fBCAP_SYS_TTY_CONFIG\fP Позволяет использовать \fBvhangup\fP(2); задействовать различные привилегированные операции \fBioctl\fP(2) с виртуальными терминалами. .TP \fBCAP_SYSLOG\fP (начиная с Linux 2.6.37) .RS .PD 0 .IP \[bu] 3 Позволяет выполнять привилегированные операции \fBsyslog\fP(2). Смотрите в \fBsyslog\fP(2) какие операции требуют прав. .IP \[bu] Позволяет просматривать адреса ядра, показываемые в \fI/proc\fP и других интерфейсах, когда значение \fI/proc/sys/kernel/kptr_restrict\fP равно 1 (смотрите описание \fIkptr_restrict\fP в \fBproc\fP(5)). .PD .RE .TP \fBCAP_WAKE_ALARM\fP (начиная с Linux 3.0) .\" Позволяет вызывать что\-либо при пробуждении системы (устанавливать таймеры \fBCLOCK_REALTIME_ALARM\fP и \fBCLOCK_BOOTTIME_ALARM\fP). .SS "Старая и текущая реализации" Для полной реализации мандатов требуется: .IP \[bu] 3 Для всех привилегированных операций ядро должно проверять, имеет ли нить требуемый мандат в его эффективном наборе. .IP \[bu] Ядро должно предоставлять системные вызовы, позволяющие получать и изменять наборы мандатов нити. .IP \[bu] Файловая система должна поддерживать присоединение мандатов к исполняемому файлу для того, чтобы при исполнении файла у процесса повышались права согласно этим мандатам. .PP .\" Before Linux 2.6.24, only the first two of these requirements are met; since Linux 2.6.24, all three requirements are met. .SS "Замечания разработчикам ядра" При добавлении новых возможностей ядра, которые должны регулироваться мандатом, нужно учитывать некоторые моменты. .IP \[bu] 3 Цель мандатов — разделить возможности суперпользователя на части, и если программа с одним или несколькими мандатами будет скомпрометирована, то её возможности нанести вред системе будут меньше, чем от такой же программы, выполняемой с правами суперпользователя. .IP \[bu] Вы можете создать новый мандат для новой возможности или привязать возможность к одному из существующих мандатов. Чтобы сохранить набор мандатов приемлемого размера, последний вариант предпочтителен, если нет неопровержимых доводов за первый вариант (есть также техническое ограничение: размер набора мандатов в настоящее время ограничен 64 битами). .IP \[bu] Для определения какой существующий мандат мог бы лучше подойти новой возможности, просмотрите список мандатов, представленный выше. Выясните, есть ли другие возможности, требующие мандатов, которые всегда будут использоваться вместе с новой возможностью. Если новая возможность бесполезна без этих других возможностей, то нужно использовать тот же мандат как у других возможностей. .IP \[bu] \fIНе\fP используйте \fBCAP_SYS_ADMIN\fP, если этого можно избежать! С ним связана большая часть существующих проверок мандатов (смотрите часть списка выше). Его оправданно можно называть «новым суперпользователем», так как с одной стороны, он даёт широкий спектр полномочий, а с другой его широкий спектр действия означает, что данный мандат требуется многим привилегированным программам. Не делайте проблему хуже. Новые возможности, которые должны быть связаны с \fBCAP_SYS_ADMIN\fP должны \fIсильно\fP совпадать с существующими, использующими данное хранилище. .IP \[bu] .\" Если действительно необходимо создать новый мандат для новой возможности, не делайте или называйте его как «только для этой возможности». То есть, например, добавление очень специализированного \fBCAP_SYS_PACCT\fP было бы, вероятно, ошибкой. Вместо этого попытайтесь идентифицировать и назвать новый мандат более вместительным понятием, в которое могут войти и другие будущие возможности. .SS "Наборы мандатов нити" Каждая нить имеет следующие наборы мандатов, содержащие ноль или более перечисленных выше мандатов: .TP \fIPermitted\fP Ограничивающий набор эффективных мандатов, которыми наделяется нить. Этот набор также ограничивает список мандатов, которые могут быть добавлены в наследуемый набор для нити, которая не имеет мандата \fBCAP_SETPCAP\fP в своём эффективном наборе. .IP Если нить сбрасывает мандат в своём разрешительном наборе, то она не сможет получить его назад (если только не выполняется \fBexecve\fP(2) для программы с set\-user\-ID\-root или программа, чьи соответствующие мандаты файла предоставляют этот мандат). .TP \fIInheritable\fP Этот набор мандатов сохраняется при вызове \fBexecve\fP(2). Наследуемые мандаты остаются наследуемыми при выполнении любой программы, и наследуемые мандаты добавляются в разрешительный набор, если выполняющаяся программа имеет соответствующие установленные биты в файловом наследуемом наборе. .IP Так как наследуемые мандаты, обычно, не сохраняются после \fBexecve\fP(2), если выполнение происходит не от суперпользователя, то для приложений, которым нужно выполнять вспомогательные программы с повышенными мандатами, нужно использовать наружные мандаты (ambient capabilities), описанные ниже. .TP \fIEffective\fP Данный набор мандатов используется ядром при выполнении проверок прав нити. .TP \fIBounding\fP (в каждой нити начиная с Linux 2.6.25) Ограничивающий набор мандатов — это механизм, который можно использовать для ограничения мандатов, которые могут быть получены при \fBexecve\fP(2). .IP Начиная с Linux 2.6.25 данный набор мандатов есть у каждой нити. В старых ядрах ограничивающий набор мандатов был системным свойством, единым для всех нитей в системе. .IP For more details, see \fICapability bounding set\fP below. .TP \fIAmbient\fP (начиная с Linux 4.3) .\" commit 58319057b7847667f0c9585b9de0e8932b0fdb08 Данный набор мандатов сохраняется после \fBexecve\fP(2) для непривилегированных программ. Для набора наружных мандатов (ambient capability set) соблюдается правило, что ни один мандат не сможет быть наружным, если он одновременно разрешающий и наследуемый. .IP Набор наружных мандатов можно непосредственно изменять с помощью \fBprctl\fP(2). Наружные мандаты автоматически понижаются, если понижаются соответствующие разрешительные или наследуемые мандаты. .IP При запуске программы, у которой изменяются UID или GID из\-за set\-user\-ID или set\-group\-ID, или у которой установлен любой набор файловых мандатов, наружный набор будет очищен. Наружные мандаты добавляются в разрешающий набори назначаются в эффективный набор при вызове \fBexecve\fP(2). Если из\-за наружных мандатов увеличиваются разрешающий и эффективный наборы при \fBexecve\fP(2), то это не вызывает режима безопасного выполнения, описанного в \fBld.so\fP(8). .PP A child created via \fBfork\fP(2) inherits copies of its parent's capability sets. For details on how \fBexecve\fP(2) affects capabilities, see \fITransformation of capabilities during execve()\fP below. .PP Using \fBcapset\fP(2), a thread may manipulate its own capability sets; see \fIProgrammatically adjusting capability sets\fP below. .PP .\" commit 73efc0394e148d0e15583e13712637831f926720 .\" Начиная с Linux 3.2, файл \fI/proc/sys/kernel/cap_last_cap\fP содержит числовое значение самого большого мандата, поддерживаемого работающим ядром; это может быть использовано для определения наибольшего бита, который может быть установлен в наборе мандатов. .SS "Файловые мандаты" Since Linux 2.6.24, the kernel supports associating capability sets with an executable file using \fBsetcap\fP(8). The file capability sets are stored in an extended attribute (see \fBsetxattr\fP(2) and \fBxattr\fP(7)) named \fIsecurity.capability\fP. Writing to this extended attribute requires the \fBCAP_SETFCAP\fP capability. The file capability sets, in conjunction with the capability sets of the thread, determine the capabilities of a thread after an \fBexecve\fP(2). .PP Три файловых набора мандатов: .TP \fIPermitted\fP (ранее называвшийся \fIforced\fP): Эти мандаты автоматически разрешаются нити независимо от унаследованных мандатов нити. .TP \fIInheritable\fP (ранее называвшийся \fIallowed\fP): Этот набор объединяется (AND) с унаследованным набором нити для определения, какие унаследованные мандаты будут включены в разрешительный набор нити после \fBexecve\fP(2). .TP \fIEffective\fP: В действительности, это не набор, а одиночный бит. Если бит включён, то при вызове \fBexecve\fP(2) все новые разрешённые мандаты нити будут также добавлены в эффективный набор. Если бит выключен, то после \fBexecve\fP(2) ни один из новых разрешённых мандатов не будет добавлен в новый эффективный набор. .IP .\" Enabling the file effective capability bit implies that any file permitted or inheritable capability that causes a thread to acquire the corresponding permitted capability during an \fBexecve\fP(2) (see \fITransformation of capabilities during execve()\fP below) will also acquire that capability in its effective set. Therefore, when assigning capabilities to a file (\fBsetcap\fP(8), \fBcap_set_file\fP(3), \fBcap_set_fd\fP(3)), if we specify the effective flag as being enabled for any capability, then the effective flag must also be specified as enabled for all other capabilities for which the corresponding permitted or inheritable flag is enabled. .SS "Версии расширенного атрибута файловых мандатов" С целью расширяемости ядро поддерживает схему кодирования номера версии внутри расширенного атрибута \fIsecurity.capability\fP, который используется в реализации файловых мандатов. Эти номера версий введены только для реализации и непосредственно не видны приложениям пользовательского пространства. В настоящее время поддерживаются следующие версии: .TP \fBVFS_CAP_REVISION_1\fP Первоначальная реализация файловых мандатов, поддерживает 32\-битные маски файловых мандатов. .TP \fBVFS_CAP_REVISION_2\fP (начиная с Linux 2.6.25) .\" commit e338d263a76af78fe8f38a72131188b58fceb591 В данной версии поддерживаются 64\-битные маски файловых мандатов, и и новый номер версии стал необходим для поддержки мандатов более 32. Ядро продолжает прозрачно поддерживать выполнение файлов с 32\-битными масками мандатов 1\-й версии, но при добавлении мандатов к файлам, у которых их ещё не было, или при изменение мандатов существующих файлов, оно автоматически использует схему 2\-й версии (или, возможно, схему 3\-ей версии как описано далее). .TP \fBVFS_CAP_REVISION_3\fP (начиная с Linux 4.14) .\" commit 8db6c34f1dbc8e06aa016a9b829b06902c3e1340 Версия 3 файловые мандатов предоставляет поддержку файловых мандатов пространства имён (описано далее). .IP Как и в версии 2, версия 3 имеет 64\-битную маску файловых мандатов. Но в дополнении, в расширенном атрибуте \fIsecurity.capability\fP кодируется ID суперпользователя пространства имён (ID суперпользователя пространства имён — это значение, на которое отображается пользовательский ID 0 этого пространства имён в изначальном пользовательском пространстве имён). .IP Файловые мандаты версии 3 могут сосуществовать с мандатами версии 2; то есть в современной системе Linux одни файлы могут быть с мандатами версии 2, а другие с версией 3. .PP До Linux 4.14 типом мандата расширенного атрибута, который мог быть присоединён к файлу, был только атрибут \fBVFS_CAP_REVISION_2\fP. Начиная с Linux 4.14 версия расширенного атрибута \fIsecurity.capability\fP, присоединённого к файлу, зависит от обстоятельств, при которых был создан атрибут. .PP Начиная с Linux 4.14, расширенный атрибут \fIsecurity.capability\fP автоматически создаётся (или преобразуется) как атрибут версии 3 (\fBVFS_CAP_REVISION_3\fP), если оба условия истинны: .IP \[bu] 3 Нить, записывающая атрибут, расположена не в изначальном пользовательском пространстве имён (более точно: нить располагается в пользовательском пространстве имён отличном от того, из которого смонтирована нижележащая файловая система). .IP \[bu] Нить имеет мандат \fBCAP_SETFCAP\fP поверх файловой иноды, то есть (a) нит имеет мандат \fBCAP_SETFCAP\fP в своём собственном пользовательском пространстве имён; и (b) UID и GID файловой иноды отображаются в пользовательское пространство имён записывающего. .PP При создании расширенного атрибута \fIsecurity.capability\fP с типом \fBVFS_CAP_REVISION_3\fP ID суперпользователя пользовательского пространства имён создающей нити сохраняется в расширенном атрибуте. .PP Но при создании или изменении расширенного атрибута \fIsecurity.capability\fP из привилегированной (\fBCAP_SETFCAP\fP) нити, находящейся в пространстве имён, в котором смонтирована нижележащая файловая система (обычно, это изначальное пользовательское пространство имён), автоматически вызывает создание атрибута с версией 2 (\fBVFS_CAP_REVISION_2\fP). .PP Заметим, что создании расширенного атрибута \fIsecurity.capability\fP версии 3 происходит автоматически. То есть когда приложение пользовательского пространства записывает (\fBsetxattr\fP(2)) атрибут \fIsecurity.capability\fP в формате версии 2 ядра автоматически создаёт версию атрибут версии 3, если атрибут создаётся в условиях, описанных выше. И, соответственно, кода атрибут \fIsecurity.capability\fP версии 3 возвращается (\fBgetxattr\fP(2)) процессу, расположенному в пользовательском пространстве имён, которое было создано с ID суперпользователя (или потомком этого пользовательского пространства имён), атрибут (автоматически) упрощается до версии 2 (т. е., возвращаемое значение имеет размер атрибута версии 2 и не включает ID суперпользователя). Эти автоматические преобразования позволяют не переписывать требуемые инструменты пользовательского пространства (например, \fBsetcap\fP(1) и \fBgetcap\fP(1)) для создания и получения атрибута \fIsecurity.capability\fP версии 3. .PP .\" Заметим, что файл может иметь расширенный атрибут \fIsecurity.capability\fP версии 2 или версии 3, но не оба одновременно: создание или изменение расширенного атрибута \fIsecurity.capability\fP автоматически приведёт к изменению версии согласно условиям, в которых он изменяется. .SS "Преобразование мандатов при execve()" При \fBexecve\fP(2) ядро вычисляет новые мандаты процесса по следующему алгоритму: .PP .in +4n .EX P'(ambient) = (file is privileged) ? 0 : P(ambient) \& P'(permitted) = (P(inheritable) & F(inheritable)) | (F(permitted) & P(bounding)) | P'(ambient) \& P'(effective) = F(effective) ? P'(permitted) : P'(ambient) \& P'(inheritable) = P(inheritable) [i.e., unchanged] \& P'(bounding) = P(bounding) [i.e., unchanged] .EE .in .PP где: .RS 4 .TP P() значение набора мандатов нити до \fBexecve\fP(2) .TP P'() значение набора мандатов нити после \fBexecve\fP(2) .TP F() файловый набор мандатов .RE .PP Опишем подробней правила преобразования описанного выше мандата: .IP \[bu] 3 Набор мандатов ambient появился начиная с Linux 4.3. При определении преобразования набора ambient в \fBexecve\fP(2) привилегированный файл — это файл, имеющий один из этих мандатов, или у него установлен бит set\-user\-ID или set\-group\-ID. .IP \[bu] До Linux 2.6.25 ограничивающий набор мандатов был общесистемным атрибутом, общим для всех нитей. Его значение использовалось для вычисления нового разрешительного набора в \fBexecve\fP(2) таким же образом как для \fIP(bounding)\fP, показанном выше. .PP \fIЗамечание\fP: во время изменений мандатов, описанных выше, файловые мандаты могут игнорироваться (считаться пустыми) по тем же причинам что и игнорируются биты set\-user\-ID и set\-group\-ID; смотрите \fBexecve\fP(2). Файловые мандаты также игнорируются, если ядро было загружено с параметром \fIno_file_caps\fP. .PP .\" \fINote\fP: according to the rules above, if a process with nonzero user IDs performs an \fBexecve\fP(2) then any capabilities that are present in its permitted and effective sets will be cleared. For the treatment of capabilities when a process with a user ID of zero performs an \fBexecve\fP(2), see \fICapabilities and execution of programs by root\fP below. .SS "Проверка на безопасность двоичных файлов, не отзывчивых к мандатам" Двоичный файл, не отзывчивый к мандатам (capability\-dumb binary) — это приложение, которое помечено как имеющее файловые мандаты, но не преобразованное для работы с программным интерфейсом \fBlibcap\fP(3) для управления своими мандатами (иначе говоря, это обычная set\-user\-ID\-root программа, у которой указали файловые мандаты, но код которой не был изменён для понимания мандатов). У таких приложений на файле установлен эффективный файловый мандатный бит, из\-за чего при исполнении файла у его процесса в эффективном наборе автоматически включаются разрешительные мандаты. Если ядро считает файл с установленным эффективным файловым мандатным битом не отзывчивым к мандатам, то выполняются проверки, описанные далее. .PP .\" When executing a capability\-dumb binary, the kernel checks if the process obtained all permitted capabilities that were specified in the file permitted set, after the capability transformations described above have been performed. (The typical reason why this might \fInot\fP occur is that the capability bounding set masked out some of the capabilities in the file permitted set.) If the process did not obtain the full set of file permitted capabilities, then \fBexecve\fP(2) fails with the error \fBEPERM\fP. This prevents possible security risks that could arise when a capability\-dumb application is executed with less privilege than it needs. Note that, by definition, the application could not itself recognize this problem, since it does not employ the \fBlibcap\fP(3) API. .SS "Мандаты и выполнение программ с правами root" .\" See cap_bprm_set_creds(), bprm_caps_from_vfs_cap() and .\" handle_privileged_root() in security/commoncap.c (Linux 5.0 source) Чтобы отразить обычную семантику UNIX, ядро выполняет специальные действия с файловыми мандатами, когда процесс с UID 0 (корневой) выполняет программу и когда выполняется программа с set\-user\-ID\-root. .PP After having performed any changes to the process effective ID that were triggered by the set\-user\-ID mode bit of the binary\[em]e.g., switching the effective user ID to 0 (root) because a set\-user\-ID\-root program was executed\[em]the kernel calculates the file capability sets as follows: .IP (1) 5 If the real or effective user ID of the process is 0 (root), then the file inheritable and permitted sets are ignored; instead they are notionally considered to be all ones (i.e., all capabilities enabled). (There is one exception to this behavior, described in \fISet\-user\-ID\-root programs that have file capabilities\fP below.) .IP (2) Если эффективный ID пользователя процесса равен 0 (root) или файловый эффективный бит фактически установлен, то файловый эффективный бит условно считается равным единице (включен). .PP Затем эти условные значения файлового набора мандатов используются, как описано выше, для вычисления преобразования мандатов процесса при \fBexecve\fP(2). .PP Таким образом, когда процесс с ненулевым UID запускает с помощью \fBexecve\fP(2) программу с set\-user\-ID\-root, у которой нет присоединённых мандатов, или когда процесс, чей реальный и эффективный UID равны нулю, запускают программу через \fBexecve\fP(2), вычисление новых разрешённых мандатов упрощается до: .PP .in +4n .EX P'(permitted) = P(inheritable) | P(bounding) \& P'(effective) = P'(permitted) .EE .in .PP В связи с этим, процесс получает все мандаты в своих разрешительном и эффективном наборе мандатов , за исключением заглушаемых ограничивающим набором мандатов. (В вычислении P'(permitted), значение P'(ambient) можно сократить, так как оно определяется корректным поднабором P(inheritable).) .PP .\" .\" Специальное действие для ID пользователя 0 (root), описанное в этом абзаце, можно отключить с помощью механизма securebits, описанного далее. .SS "Программы set\-user\-ID\-root с файловыми мандатами" There is one exception to the behavior described in \fICapabilities and execution of programs by root\fP above. If (a) the binary that is being executed has capabilities attached and (b) the real user ID of the process is \fInot\fP 0 (root) and (c) the effective user ID of the process \fIis\fP 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). .PP .\" Заметим, что файлу программы можно назначить пустой набор мандатов, и таким образом возможно создать программу с set\-user\-ID\-root, которая изменяет эффективный и сохранённый set\-user\-ID процесса, исполняющего программу, на 0, но не даёт мандаты этому процессу. .SS "Ограничивающий набор мандатов" Ограничивающий набор мандатов — это механизм безопасности, который можно использовать для ограничения мандатов, которые могут быть получены при \fBexecve\fP(2). Ограничивающий набор используется так: .IP \[bu] 3 При \fBexecve\fP(2) ограничивающий набор мандатов складывается (AND) с файловым разрешительным набором мандатов, и результат этой операции назначается разрешительному набору мандатов нити. Таким образом, ограничивающий набор мандатов ограничивает разрешённые мандаты, которые может предоставить исполняемый файл. .IP \[bu] (начиная с Linux 2.6.25) Ограничивающий набор мандатов служит ограничивающим набором мандатов, которые нить может добавить в свой наследуемый набор с помощью \fBcapset\fP(2). Это означает, что если мандат отсутствует в ограничивающем наборе мандатов, то нить не может добавить этот мандат в свой наследуемый набор даже, если он есть в разрешительном наборе мандатов и поэтому не может сохранить данный мандат в разрешительный набор при вызове \fBexecve\fP(2) для файла, который имеет мандат в своём наследуемом наборе. .PP Заметим, что ограничивающий набор скрывает файловые разрешительные мандаты, но не наследуемые мандаты. Если нить имеет мандат в своём наследуемом наборе, который отсутствует в ограничивающем наборе, то она по\-прежнему обладает этим мандатом в своём разрешительном наборе при выполнении файла, который имеет мандат в своём наследуемом наборе. .PP В зависимости от версии ядра ограничивающий набор мандатов является либо системным свойством, либо атрибутом процесса. .PP \fBОграничивающий набор мандатов начиная с Linux 2.6.25\fP .PP Начиная с Linux 26.25, \fIограничивающий набор мандатов\fP является атрибутом нити (системного ограничивающего набора мандатов, описываемого далее, больше нет). .PP Ограничивающий набор наследуется при \fBfork\fP(2) от нити родителя и сохраняется при \fBexecve\fP(2). .PP Нить может удалять мандаты из своего ограничивающего набора мандатов с помощью вызова \fBprctl\fP(2) с операцией \fBPR_CAPBSET_DROP\fP при наличии мандата \fBCAP_SETPCAP\fP. После удаления мандата из ограничивающего набора обратно его восстановить невозможно. Нить может определить наличие мандата в своём ограничивающем наборе с помощью вызова \fBprctl\fP(2) с операцией \fBPR_CAPBSET_READ\fP. .PP .\" commit b3a222e52e4d4be77cc4520a57af1a4a0d8222d1 Removing capabilities from the bounding set is supported only if file capabilities are compiled into the kernel. Before Linux 2.6.33, file capabilities were an optional feature configurable via the \fBCONFIG_SECURITY_FILE_CAPABILITIES\fP option. Since Linux 2.6.33, the configuration option has been removed and file capabilities are always part of the kernel. When file capabilities are compiled into the kernel, the \fBinit\fP process (the ancestor of all processes) begins with a full bounding set. If file capabilities are not compiled into the kernel, then \fBinit\fP begins with a full bounding set minus \fBCAP_SETPCAP\fP, because this capability has a different meaning when there are no file capabilities. .PP Удаление мандата из ограничивающего набора не удаляет его из наследуемого набора нити. Однако это предотвращает от добавления мандата обратно в наследуемый набор нити в будущем. .PP \fBОграничивающий набор мандатов до Linux 2.6.25\fP .PP Before Linux 2.6.25, the capability bounding set is a system\-wide attribute that affects all threads on the system. The bounding set is accessible via the file \fI/proc/sys/kernel/cap\-bound\fP. (Confusingly, this bit mask parameter is expressed as a signed decimal number in \fI/proc/sys/kernel/cap\-bound\fP.) .PP Только процесс \fBinit\fP может задавать мандаты в ограничивающем наборе мандатов; помимо этого, суперпользователь (точнее, процесс с мандатом \fBCAP_SYS_MODULE\fP) может только удалять мандаты из набора. .PP В стандартной системе в ограничивающем наборе мандатов всегда удаляется мандат \fBCAP_SETPCAP\fP. Чтобы убрать это ограничение (опасно!), нужно изменить определение \fBCAP_INIT_EFF_SET\fP в \fIinclude/linux/capability.h\fP и пересобрать ядро. .PP .\" .\" .\" The system\-wide capability bounding set feature was added to Linux 2.2.11. .SS "Влияние изменения пользовательского ID на мандаты" Для сохранения привычной семантики при переходе от 0 к ненулевым пользовательским ID, ядро делает следующие изменения наборов мандатов нити при изменении у нити реального, эффективного, сохранённого ID и пользовательского ID файловой системы (с помощью \fBsetuid\fP(2), \fBsetresuid\fP(2) или подобных): .IP \[bu] 3 If one or more of the real, effective, or saved set user IDs was previously 0, and as a result of the UID changes all of these IDs have a nonzero value, then all capabilities are cleared from the permitted, effective, and ambient capability sets. .IP \[bu] Если эффективный пользовательский ID изменяется с 0 на ненулевое значение, то все мандаты удаляются из эффективного набора мандатов. .IP \[bu] Если эффективный пользовательский ID изменяется с ненулевого значения на 0, то разрешительный набор копируется в эффективный набор. .IP \[bu] Если пользовательский ID файловой системы изменяется с 0 на ненулевое значение (смотрите \fBsetfsuid\fP(2)), то следующие мандаты удаляются из эффективного набора: \fBCAP_CHOWN\fP, \fBCAP_DAC_OVERRIDE\fP, \fBCAP_DAC_READ_SEARCH\fP, \fBCAP_FOWNER\fP, \fBCAP_FSETID\fP, \fBCAP_LINUX_IMMUTABLE\fP (начиная с Linux 2.6.30), \fBCAP_MAC_OVERRIDE\fP и \fBCAP_MKNOD\fP (начиная с Linux 2.6.30). Если пользовательский ID файловой системы изменяется с ненулевого значения на 0, то любой из мандатов, включённых в разрешительный набор, включается в эффективном наборе. .PP .\" Если нить, у которой один или более пользовательских ID равно 0, хочет предотвратить удаление разрешительных мандатов при сбросе всех пользовательских ID в ненулевые значения, то она может использовать флаг \fBSECBIT_KEEP_CAPS\fP в securebits, описанный далее. .SS "Программное изменение наборов мандатов" Нить может получать и изменять свои разрешительные, действующие и наследуемые наборы мандатов с помощью системных вызовов \fBcapget\fP(2) и \fBcapset\fP(2). Однако для этой цели лучше использовать \fBcap_get_proc\fP(3) и \fBcap_set_proc\fP(3) из пакета \fIlibcap\fP. Следующие правила применяются при изменении наборов нити: .IP \[bu] 3 Если вызывающий не имеет мандата \fBCAP_SETPCAP\fP, то новый наследуемый набор должен быть поднабором комбинации существующего наследуемого и разрешительного наборов. .IP \[bu] (начиная с Linux 2.6.25) Новый наследуемый набор должен быть поднабором комбинации существующего наследуемого и ограничивающего наборов. .IP \[bu] Новый разрешительный набор должен быть поднабором существующего разрешительного набора (т. е., невозможно приобрести разрешительные мандаты, которых нить не имеет). .IP \[bu] Новый эффективный набор должен быть поднабором нового разрешительного набора. .SS "Флаги securebits: организация исключительно мандатного окружения" .\" For some background: .\" see http://lwn.net/Articles/280279/ and .\" http://article.gmane.org/gmane.linux.kernel.lsm/5476/ Starting with Linux 2.6.26, and with a kernel in which file capabilities are enabled, Linux implements a set of per\-thread \fIsecurebits\fP flags that can be used to disable special handling of capabilities for UID 0 (\fIroot\fP). These flags are as follows: .TP \fBSECBIT_KEEP_CAPS\fP Установка этого флага позволяет нити иметь один или более 0 UIDов, чтобы оставить мандаты в разрешительном наборе, когда она переключается все свои UIDы в ненулевые значения. Если этот флаг не установлен, то переключение такого UID приводит к тому, что нить теряет все мандаты в этих наборах. Этот флаг всегда сбрасывается при \fBexecve\fP(2). .IP Заметим, что даже с установленным флагом \fBSECBIT_KEEP_CAPS\fP эффективные мандаты нити очищаются, когда она переключает свой эффективный UID на ненулевое значение. Однако, если нить устанавливает этот флаг и её эффективный UID уже не равен нулю и затем нить переключает все другие UID в ненулевые значения, то эффективные мандаты не будут очищены. .IP Установка флага \fBSECBIT_KEEP_CAPS\fP игнорируется, если указан флаг \fBSECBIT_NO_SETUID_FIXUP\fP (этот флаг предоставляет надмножество свойств первого флага). .IP Этот флаг предоставляет возможности старой операции \fBPR_SET_KEEPCAPS\fP вызова \fBprctl\fP(2). .TP \fBSECBIT_NO_SETUID_FIXUP\fP Setting this flag stops the kernel from adjusting the process's permitted, effective, and ambient capability sets when the thread's effective and filesystem UIDs are switched between zero and nonzero values. See \fIEffect of user ID changes on capabilities\fP above. .TP \fBSECBIT_NOROOT\fP If this bit is set, then the kernel does not grant capabilities when a set\-user\-ID\-root program is executed, or when a process with an effective or real UID of 0 calls \fBexecve\fP(2). (See \fICapabilities and execution of programs by root\fP above.) .TP \fBSECBIT_NO_CAP_AMBIENT_RAISE\fP Установка этого флага запрещает повышение наружных мандатов посредством \fBprctl\fP(2)с операцией \fBPR_CAP_AMBIENT_RAISE\fP. .PP Каждый из перечисленных выше «базовых» флагов имеет дополнительный флаг «блокировки». Установка любого из флагов «блокировки» необратима и запрещает дальнейшие изменения соответствующего «базового» флага. Флаги блокировки: \fBSECBIT_KEEP_CAPS_LOCKED\fP, \fBSECBIT_NO_SETUID_FIXUP_LOCKED\fP, \fBSECBIT_NOROOT_LOCKED\fP и \fBSECBIT_NO_CAP_AMBIENT_RAISE_LOCKED\fP. .PP Флаги \fIsecurebits\fP можно изменять и получать с помощью вызова \fBprctl\fP(2) с операциями \fBPR_SET_SECUREBITS\fP и \fBPR_GET_SECUREBITS\fP. Для изменения флагов требуется мандат \fBCAP_SETPCAP\fP. Заметим, что константы \fBSECBIT_*\fP доступны только после включения в код заголовочного файла \fI\fP. .PP Флаги \fIsecurebits\fP наследуются дочерними процессами. При \fBexecve\fP(2) все флаги сохраняются, за исключением \fBSECBIT_KEEP_CAPS\fP, который всегда сбрасывается. .PP Приложение может использовать следующий вызов для собственной блокировки и помещение всех своих потомков в окружение, в котором есть только один способ добавить права — запустить программу со связанными с ней файловыми мандатами: .PP .in +4n .EX 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); /* установка/блокировка SECBIT_NO_CAP_AMBIENT_RAISE не требуется */ .EE .in .\" .\" .SS "Программы set\-user\-ID\-root с отдельными пространствами имён пользователя" Программе set\-user\-ID, чей UID совпадает с UID создателя пространства имён пользователя, будут предоставлены мандаты в разрешительном и эффективном наборах, при выполнении любого процесса внутри этого пространства имён или в любом дочернем пространстве имён пользователя. .PP .\" .\" The rules about the transformation of the process's capabilities during the \fBexecve\fP(2) are exactly as described in \fITransformation of capabilities during execve()\fP and \fICapabilities and execution of programs by root\fP above, with the difference that, in the latter subsection, "root" is the UID of the creator of the user namespace. .SS "Файловые мандаты пространства имён" .\" commit 8db6c34f1dbc8e06aa016a9b829b06902c3e1340 Traditional (i.e., version 2) file capabilities associate only a set of capability masks with a binary executable file. When a process executes a binary with such capabilities, it gains the associated capabilities (within its user namespace) as per the rules described in \fITransformation of capabilities during execve()\fP above. .PP Так как файловые мандаты версии 2 предоставляются выполняющемуся процессу независимо от того, в каком пользовательском пространстве имён он располагается, то только привилегированным процессам разрешено связывать мандаты с файлом. Здесь «привилегированным» считается процесс, имеющий мандат \fBCAP_SETFCAP\fP в пользовательском пространстве имён, в котором была смонтирована файловая система (обычно, изначальное пользовательское пространство имён). Это ограничение в определённых случаях делает файловые мандаты бесполезными. Например, в контейнерах пользовательских пространств имён может требоваться возможность создания двоичных файлов, которые предоставляют мандаты только процессам, выполняемым внутри контейнера, но не процессам, выполняемым вне контейнера. .PP Linux 4.14 added so\-called namespaced file capabilities to support such use cases. Namespaced file capabilities are recorded as version 3 (i.e., \fBVFS_CAP_REVISION_3\fP) \fIsecurity.capability\fP extended attributes. Such an attribute is automatically created in the circumstances described in \fIFile capability extended attribute versioning\fP above. When a version 3 \fIsecurity.capability\fP extended attribute is created, the kernel records not just the capability masks in the extended attribute, but also the namespace root user ID. .PP .\" .\" Подобно двоичному файлу с файловыми мандатами \fBVFS_CAP_REVISION_2\fP файл с файловыми мандатами \fBVFS_CAP_REVISION_3\fP предоставляет мандаты процессу при \fBexecve\fP(). Однако мандаты предоставляются только, если двоичный файл, выполняемый процессом, располагается в пользовательском пространстве имён, в котором UID 0 отображается в ID суперпользователя, сохранённого в расширенном атрибуте, или когда выполняется процессом, располагаемом в потомке такого пространства имён. .SS "Взаимодействие с пользовательскими пространствами имён" Дополнительную информацию о связи мандатов с пространствами пользователя смотрите в \fBuser_namespaces\fP(7). .SH СТАНДАРТЫ No standards govern capabilities, but the Linux capability implementation is based on the withdrawn .UR https://archive.org\:/details\:/posix_1003.1e\-990310 POSIX.1e draft standard .UE . .SH ЗАМЕЧАНИЯ При попытке запуска \fBstrace\fP(1) над исполняемыми файлами с мандатами (или с установленным битом set\-user\-ID\-root), вам может понадобиться параметр \fI\-u <имя_пользователя>\fP. Например так: .PP .in +4n .EX $ \fBsudo strace \-o trace.log \-u ceci ./myprivprog\fP .EE .in .PP .\" commit 5915eb53861c5776cfec33ca4fcc1fd20d66dd27 removed .\" CONFIG_SECURITY_CAPABILITIES From Linux 2.5.27 to Linux 2.6.26, capabilities were an optional kernel component, and could be enabled/disabled via the \fBCONFIG_SECURITY_CAPABILITIES\fP kernel configuration option. .PP .\" 7b9a7ec565505699f503b4fcf61500dceb36e744 The \fI/proc/\fPpid\fI/task/TID/status\fP file can be used to view the capability sets of a thread. The \fI/proc/\fPpid\fI/status\fP file shows the capability sets of a process's main thread. Before Linux 3.8, nonexistent capabilities were shown as being enabled (1) in these sets. Since Linux 3.8, all nonexistent capabilities (above \fBCAP_LAST_CAP\fP) are shown as disabled (0). .PP В пакете \fIlibcap\fP содержится набор процедур для установки и получения мандатов; он удобнее и менее подвержен изменениям, чем интерфейс предоставляемый \fBcapset\fP(2) и \fBcapget\fP(2). Также данный пакет предоставляет программы \fBsetcap\fP(8) и \fBgetcap\fP(8) . Его можно найти здесь: .br .UR https://git.kernel.org\:/pub\:/scm\:/libs\:/libcap\:/libcap.git\:/refs/ .UE . .PP Before Linux 2.6.24, and from Linux 2.6.24 to Linux 2.6.32 if file capabilities are not enabled, a thread with the \fBCAP_SETPCAP\fP capability can manipulate the capabilities of threads other than itself. However, this is only theoretically possible, since no thread ever has \fBCAP_SETPCAP\fP in either of these cases: .IP \[bu] 3 In the pre\-2.6.25 implementation the system\-wide capability bounding set, \fI/proc/sys/kernel/cap\-bound\fP, always masks out the \fBCAP_SETPCAP\fP capability, and this can not be changed without modifying the kernel source and rebuilding the kernel. .IP \[bu] If file capabilities are disabled (i.e., the kernel \fBCONFIG_SECURITY_FILE_CAPABILITIES\fP option is disabled), then \fBinit\fP starts out with the \fBCAP_SETPCAP\fP capability removed from its per\-process bounding set, and that bounding set is inherited by all other processes created on the system. .SH "СМ. ТАКЖЕ" .\" from libcap-ng .\" from libcap-ng .\" from libcap-ng .\" from libcap-ng \fBcapsh\fP(1), \fBsetpriv\fP(1), \fBprctl\fP(2), \fBsetfsuid\fP(2), \fBcap_clear\fP(3), \fBcap_copy_ext\fP(3), \fBcap_from_text\fP(3), \fBcap_get_file\fP(3), \fBcap_get_proc\fP(3), \fBcap_init\fP(3), \fBcapgetp\fP(3), \fBcapsetp\fP(3), \fBlibcap\fP(3), \fBproc\fP(5), \fBcredentials\fP(7), \fBpthreads\fP(7), \fBuser_namespaces\fP(7), \fBcaptest\fP(8), \fBfilecap\fP(8), \fBgetcap\fP(8), \fBgetpcaps\fP(8), \fBnetcap\fP(8), \fBpscap\fP(8), \fBsetcap\fP(8) .PP Файл \fIinclude/linux/capability.h\fP в дереве исходного кода ядра Linux. .PP .SH ПЕРЕВОД Русский перевод этой страницы руководства был сделан Azamat Hackimov , Dmitriy S. Seregin , Dmitry Bolkhovskikh , Katrin Kutepova , Yuri Kozlov и Иван Павлов . .PP Этот перевод является бесплатной документацией; прочитайте .UR https://www.gnu.org/licenses/gpl-3.0.html Стандартную общественную лицензию GNU версии 3 .UE или более позднюю, чтобы узнать об условиях авторского права. Мы не несем НИКАКОЙ ОТВЕТСТВЕННОСТИ. .PP Если вы обнаружите ошибки в переводе этой страницы руководства, пожалуйста, отправьте электронное письмо на .MT man-pages-ru-talks@lists.sourceforge.net .ME .