.\" -*- coding: UTF-8 -*-
.\" Copyright, the authors of the Linux man-pages project
.\"
.\" SPDX-License-Identifier: Linux-man-pages-copyleft
.\"
.\"*******************************************************************
.\"
.\" This file was generated with po4a. Translate the source file.
.\"
.\"*******************************************************************
.TH Capacidades 7 "17 maio 2025" "Linux man\-pages 6.15" 
.SH NOME
capabilities \- visão geral das capacidades do Linux
.SH DESCRIÇÃO
Para fins de executar verificações de permissão, implementações UNIX
tradicionais distinguem duas categorias de processos: processos
\fIprivilegiados\fP (cujo ID de usuário efetivo é 0, chamado de superusuário ou
root) e processos \fIdesprivilegiados\fP (cujo UID efetivo é diferente de
zero). Processos privilegiados ignoram todas as verificações de permissão do
kernel, enquanto processos não privilegiados estão sujeitos à verificação de
permissão completa com base nas credenciais do processo (geralmente: UID
efetivo, GID efetivo e lista de grupos suplementares).
.P
.\"
A partir do Linux 2.2, o Linux divide os privilégios tradicionalmente
associados ao superusuário em unidades distintas, conhecidas como
\fIcapacidades\fP (em inglês \fIcapabilities\fP), que podem ser habilitadas e
desabilitadas independentemente. Capacidades são um atributo por thread.
.SS "Lista de capacidades"
A lista a seguir mostra as capacidades implementadas no Linux e as operações
ou comportamentos que cada capacidade permite:
.TP 
\fBCAP_AUDIT_CONTROL\fP (desde o Linux 2.6.11)
Habilitar e desabilitar auditoria do kernel; alterar regras de filtro de
auditoria; recuperar status de auditoria e regras de filtragem.
.TP 
\fBCAP_AUDIT_READ\fP (desde o Linux 3.16)
.\" commit a29b694aa1739f9d76538e34ae25524f9c549d59
.\" commit 3a101b8de0d39403b2c7e5c23fd0b005668acf48
Permitir leitura do log de auditoria por meio de um soquete netlink
multicast.
.TP 
\fBCAP_AUDIT_WRITE\fP (desde o Linux 2.6.11)
.\" FIXME Add FAN_ENABLE_AUDIT
Gravar registros no log de auditoria do kernel.
.TP 
\fBCAP_BLOCK_SUSPEND\fP (desde o Linux 3.5)
Empregar recursos que podem bloquear a suspensão do sistema (\fBepoll\fP(7)
\fBEPOLLWAKEUP\fP, \fI/proc/sys/wake_lock\fP).
.TP 
\fBCAP_BPF\fP (desde o Linux 5.8)
Empregar operações BPF privilegiadas; veja \fBbpf\fP(2) e \fBbpf\-helpers\fP(7).
.IP
Esta capacidade foi adicionada no Linux 5.8 para separar a funcionalidade
BPF da capacidade sobrecarregada \fBCAP_SYS_ADMIN\fP.
.TP 
\fBCAP_CHECKPOINT_RESTORE\fP (desde o Linux 5.9)
.\" commit 124ea650d3072b005457faed69909221c2905a1f
.PD 0
.RS
.IP \[bu] 3
Atualizar \fI/proc/sys/kernel/ns_last_pid\fP (veja \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().
empregar o recurso \fIset_tid\fP de \fBclone3\fP(2);
.IP \[bu]
ler o conteúdo dos links simbólicos em \fI/proc/\fPpid\fI/map_files\fP para outros
processos.
.RE
.PD
.IP
Esta capacidade foi adicionada no Linux 5.9 para separar a funcionalidade
checkpoint/restore da capacidade sobrecarregada \fBCAP_SYS_ADMIN\fP.
.TP 
\fBCAP_CHOWN\fP
Fazer alterações arbitrárias em UIDs e GIDs de arquivo (veja \fBchown\fP(2)).
.TP 
\fBCAP_DAC_OVERRIDE\fP
Ignorar verificações de permissão de leitura, gravação e execução de
arquivo. (DAC é uma abreviação de "controle de acesso discricionário" em
inglês.)
.TP 
\fBCAP_DAC_READ_SEARCH\fP
.PD 0
.RS
.IP \[bu] 3
Ignorar verificações de permissão de leitura de arquivo e verificações de
permissão de leitura e execução de diretório;
.IP \[bu]
invoca \fBopen_by_handle_at\fP(2);
.IP \[bu]
usar o sinalizador \fBlinkat\fP(2) \fBAT_EMPTY_PATH\fP para criar um link para um
arquivo referenciado por um descritor de arquivo.
.RE
.PD
.TP 
\fBCAP_FOWNER\fP
.PD 0
.RS
.IP \[bu] 3
Ignorar verificações de permissão em operações que normalmente exigem que o
UID do sistema de arquivos do processo corresponda ao UID do arquivo (por
exemplo, \fBchmod\fP(2), \fButime\fP(2)), excluindo as operações cobertas por
\fBCAP_DAC_OVERRIDE\fP e \fBCAP_DAC_READ_SEARCH\fP;
.IP \[bu]
definir sinalizadores de inode (consulte \fBFS_IOC_SETFLAGS\fP(2const)) em
arquivos arbitrários;
.IP \[bu]
definir listas de controle de acesso (ACLs) em arquivos arbitrários;
.IP \[bu]
ignorar sticky bit de diretório na exclusão de arquivo;
.IP \[bu]
modificar atributos estendidos de \fIusuário\fP em diretório sticky de
propriedade de qualquer usuário;
.IP \[bu]
especificar \fBO_NOATIME\fP para arquivos arbitrários em \fBopen\fP(2) e
\fBfcntl\fP(2).
.RE
.PD
.TP 
\fBCAP_FSETID\fP
.PD 0
.RS
.IP \[bu] 3
Não limpar bits de modo set\-user\-ID e set\-group\-ID quando um arquivo for
modificado;
.IP \[bu]
definir o bit set\-group\-ID para um arquivo cujo GID não corresponde ao
sistema de arquivos ou a qualquer um dos GIDs suplementares do processo de
chamada.
.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
Bloquear a memória (\fBmlock\fP(2), \fBmlockall\fP(2), \fBmmap\fP(2), \fBshmctl\fP(2));
.IP \[bu]
Alocar memória usando páginas enormes (\fBmemfd_create\fP(2), \fBmmap\fP(2),
\fBshmctl\fP(2)).
.RE
.PD
.TP 
\fBCAP_IPC_OWNER\fP
Ignorar verificações de permissão para operações em objetos IPC do System V.
.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?
Ignorar verificações de permissão para enviar sinais (consulte
\fBkill\fP(2)). Isso inclui o uso da operação \fBioctl\fP(2) \fBKDSIGACCEPT\fP.
.TP 
\fBCAP_LEASE\fP (desde o Linux 2.4)
Estabelecer concessões em arquivos arbitrários (consulte \fBfcntl\fP(2)).
.TP 
\fBCAP_LINUX_IMMUTABLE\fP
Definir os sinalizadores de inode \fBFS_APPEND_FL\fP e \fBFS_IMMUTABLE_FL\fP
(consulte \fBFS_IOC_SETFLAGS\fP(2const)).
.TP 
\fBCAP_MAC_ADMIN\fP (desde o Linux 2.6.25)
Permitir configuração de MAC ou alterações de estado. Implementada para o
Smack Linux Security Module (LSM).
.TP 
\fBCAP_MAC_OVERRIDE\fP (desde o Linux 2.6.25)
Substituir o Mandatory Access Control (MAC). Implementada para o Smack LSM.
.TP 
\fBCAP_MKNOD\fP (desde o Linux 2.4)
Criar arquivos especiais usando \fBmknod\fP(2).
.TP 
\fBCAP_NET_ADMIN\fP
Executar várias operações relacionadas a rede:
.PD 0
.RS
.IP \[bu] 3
configuração de interface;
.IP \[bu]
administração de firewall de IP, de m e contas;
.IP \[bu]
modificar tabelas de roteamento;
.IP \[bu]
vincular a qualquer endereço para proxy transparente;
.IP \[bu]
definir o tipo de serviço (TOS);
.IP \[bu]
limpar estatísticas do driver;
.IP \[bu]
definir o modo promíscuo;
.IP \[bu]
habilitar multicasting;
.IP \[bu]
usar \fBsetsockopt\fP(2) para definir as seguintes opções de soquete:
\fBSO_DEBUG\fP, \fBSO_MARK\fP, \fBSO_PRIORITY\fP (para uma prioridade fora do
intervalo de 0 a 6), \fBSO_RCVBUFFORCE\fP e \fBSO_SNDBUFFORCE\fP.
.RE
.PD
.TP 
\fBCAP_NET_BIND_SERVICE\fP
Vincular um socket a portas privilegiadas de domínio da Internet (números de
porta menores que 1024).
.TP 
\fBCAP_NET_BROADCAST\fP
.\" FIXME Since Linux 4.2, there are use cases for netlink sockets
.\"    commit 59324cf35aba5336b611074028777838a963d03b
(Não usado) Fazer transmissões de socket e ouvir multicasts.
.TP 
\fBCAP_NET_RAW\fP
.PD 0
.RS
.IP \[bu] 3
Usar sockets RAW e PACKET;
.IP \[bu]
vincular a qualquer endereço para proxy transparente.
.RE
.PD
.\" Also various IP options and setsockopt(SO_BINDTODEVICE)
.TP 
\fBCAP_PERFMON\fP (desde o Linux 5.8)
Empregar vários mecanismos de monitoramento de desempenho, incluindo:
.RS
.IP \[bu] 3
.PD 0
chamar \fBperf_event_open\fP(2);
.IP \[bu]
empregar várias operações BPF que têm implicações de desempenho.
.RE
.PD
.IP
Esta capacidade foi adicionada no Linux 5.8 para separar a funcionalidade de
monitoramento de desempenho da capacidade sobrecarregada
\fBCAP_SYS_ADMIN\fP. Veja também o arquivo\-fonte do kernel
\fIDocumentation/admin\-guide/perf\-security.rst\fP.
.TP 
\fBCAP_SETGID\fP
.RS
.PD 0
.IP \[bu] 3
Fazer manipulações arbitrárias de GIDs de processo e listar de GID
suplementar;
.IP \[bu]
forjar GID ao passar credenciais de socket por meio de sockets de domínio
UNIX;
.IP \[bu]
escrever um mapeamento de ID de grupo em um espaço de nomes de usuário (veja
\fBuser_namespaces\fP(7)).
.PD
.RE
.TP 
\fBCAP_SETFCAP\fP (desde o Linux 2.6.24)
Definir capacidades arbitrárias em um arquivo.
.IP
.\" commit db2e718a47984b9d71ed890eb2ea36ecf150de18
Desde o Linux 5.12, esse recurso também é necessário para mapear o ID do
usuário 0 em um novo espaço de nomes de usuário; veja \fBuser_namespaces\fP(7)
para detalhes.
.TP 
\fBCAP_SETPCAP\fP
Se os recursos de arquivo forem suportados (isto é, desde o Linux 2.6.24):
adicionar qualquer recurso do conjunto delimitador da thread de chamada ao
seu conjunto herdável; remover recursos do conjunto delimitador (por meio de
\fBprctl\fP(2) \fBPR_CAPBSET_DROP\fP); fazer alterações nos sinalizadores
\fIsecurebits\fP.
.IP
Se os recursos de arquivo não forem suportados (isto é, antes do Linux
2.6.24): conceder ou remover qualquer recurso no conjunto de recursos
permitidos do chamador para ou de qualquer outro processo. (esta propriedade
de \fBCAP_SETPCAP\fP não está disponível quando o kernel é configurado para
suportar recursos de arquivo, já que \fBCAP_SETPCAP\fP tem semânticas
totalmente diferentes para tais kernels.)
.TP 
\fBCAP_SETUID\fP
.RS
.PD 0
.IP \[bu] 3
Fazer manipulações arbitrárias de UIDs de processo (\fBsetuid\fP(2),
\fBsetreuid\fP(2), \fBsetresuid\fP(2), \fBsetfsuid\fP(2));
.IP \[bu]
forjar UID ao passar credenciais de soquete por meio de soquetes de domínio
UNIX;
.IP \[bu]
escrever um mapeamento de ID de usuário em um espaço de nomes de usuário
(consulte \fBuser_namespaces\fP(7)).
.PD
.RE
.\" FIXME CAP_SETUID also an effect in exec(); document this.
.TP 
\fBCAP_SYS_ADMIN\fP
\fINota\fP: esta capacidade está sobrecarregada; consulte \fINotas para desenvolvedores de kernel\fP abaixo.
.IP
.PD 0
.RS
.IP \[bu] 3
Executar uma série de operações de administração do sistema, incluindo:
\fBquotactl\fP(2), \fBmount\fP(2), \fBumount\fP(2), \fBpivot_root\fP(2), \fBswapon\fP(2),
\fBswapoff\fP(2), \fBsethostname\fP(2) e \fBsetdomainname\fP(2);
.IP \[bu]
executar operações privilegiadas de \fBsyslog\fP(2) (desde o Linux 2.6.37,
\fBCAP_SYSLOG\fP deve ser usado para permitir tais operações);
.IP \[bu]
executar o comando \fBVM86_REQUEST_IRQ\fP \fBvm86\fP(2);
.IP \[bu]
acessar a mesma funcionalidade de checkpoint/restauração que é governada por
\fBCAP_CHECKPOINT_RESTORE\fP (mas a última, capacidade mais fraca, é preferida
para acessar essa funcionalidade).
.IP \[bu]
executar as mesmas operações BPF que são governadas por \fBCAP_BPF\fP (mas a
última, capacidade mais fraca, é preferida para acessar essa
funcionalidade).
.IP \[bu]
empregar os mesmos mecanismos de monitoramento de desempenho que são
governados por \fBCAP_PERFMON\fP (mas a última, capacidade mais fraca, é
preferida para acessar essa funcionalidade).
.IP \[bu]
executar operações \fBIPC_SET\fP e \fBIPC_RMID\fP em objetos IPC arbitrários do
System V;
.IP \[bu]
substituir limite de recurso \fBRLIMIT_NPROC\fP;
.IP \[bu]
executar operações em atributos estendidos \fItrusted\fP e \fIsecurity\fP
(consulte \fBxattr\fP(7));
.IP \[bu]
usar \fBlookup_dcookie\fP(2);
.IP \[bu]
usar \fBioprio_set\fP(2) para atribuir classes de agendamento de E/S
\fBIOPRIO_CLASS_RT\fP e (antes do Linux 2.6.25) \fBIOPRIO_CLASS_IDLE\fP;
.IP \[bu]
forjar PID ao passar credenciais de soquete por soquetes de domínio UNIX;
.IP \[bu]
exceder \fI/proc/sys/fs/file\-max\fP, o limite de todo o sistema no número de
arquivos abertos, em chamadas de sistema que abrem arquivos (por exemplo,
\fBaccept\fP(2), \fBexecve\fP(2), \fBopen\fP(2), \fBpipe\fP(2));
.IP \[bu]
empregar sinalizadores \fBCLONE_*\fP que criam novos espaços de nomes com
\fBclone\fP(2) e \fBunshare\fP(2) (mas, desde o Linux 3.8, criar espaços de nomes
de usuário não requer nenhuma capacidade);
.IP \[bu]
acessar informações privilegiadas de eventos \fIperf\fP;
.IP \[bu]
chamar \fBsetns\fP(2) (requer \fBCAP_SYS_ADMIN\fP no espaço de nomes \fItarget\fP);
.IP \[bu]
chamar \fBfanotify_init\fP(2);
.IP \[bu]
executar operações privilegiadas \fBKEYCTL_CHOWN\fP e \fBKEYCTL_SETPERM\fP do
\fBkeyctl\fP(2);
.IP \[bu]
executar a operação \fBmadvise\fP(2) \fBMADV_HWPOISON\fP;
.IP \[bu]
empregar o \fBTIOCSTI\fP \fBioctl\fP(2) para inserir caracteres na fila de entrada
de um terminal diferente do terminal de controle do chamador;
.IP \[bu]
empregar a chamada de sistema \fBnfsservctl\fP(2) obsoleta;
.IP \[bu]
empregar a chamada de sistema \fBbdflush\fP(2) obsoleta;
.IP \[bu]
executar várias operações de dispositivo de bloco privilegiado \fBioctl\fP(2);
.IP \[bu]
executar várias operações de sistema de arquivo privilegiado \fBioctl\fP(2);
.IP \[bu]
executar operações \fBioctl\fP(2) privilegiadas no dispositivo \fI/dev/random\fP
(consulte \fBrandom\fP(4));
.IP \[bu]
instalar um filtro \fBseccomp\fP(2) sem primeiro ter que definir o atributo de
thread \fIno_new_privs\fP;
.IP \[bu]
modificar regras de permissão/negação para grupos de controle de
dispositivo;
.IP \[bu]
empregar a operação \fBptrace\fP(2) \fBPTRACE_SECCOMP_GET_FILTER\fP para despejar
os filtros seccomp do tracee;
.IP \[bu]
empregar a operação \fBptrace\fP(2) \fBPTRACE_SETOPTIONS\fP para suspender as
proteções seccomp do tracee (ou seja, o sinalizador
\fBPTRACE_O_SUSPEND_SECCOMP\fP);
.IP \[bu]
executar operações administrativas em muitos drivers de dispositivo;
.IP \[bu]
modificar valores de nice ​​do autogroup escrevendo em
\fI/proc/\fPpid\fI/autogroup\fP (consulte \fBsched\fP(7)).
.RE
.PD
.TP 
\fBCAP_SYS_BOOT\fP
Usar \fBreboot\fP(2) e \fBkexec_load\fP(2).
.TP 
\fBCAP_SYS_CHROOT\fP
.RS
.PD 0
.IP \[bu] 3
Usar \fBchroot\fP(2);
.IP \[bu]
alterar espaços de nomes de montagem usando \fBsetns\fP(2).
.PD
.RE
.TP 
\fBCAP_SYS_MODULE\fP
.RS
.PD 0
.IP \[bu] 3
Carregar e descarregar módulos do kernel (veja \fBinit_module\fP(2) e
\fBdelete_module\fP(2));
.IP \[bu]
antes do Linux 2.6.25: remover recursos do conjunto de delimitação de
recursos de todo o sistema.
.PD
.RE
.TP 
\fBCAP_SYS_NICE\fP
.PD 0
.RS
.IP \[bu] 3
Reduzir o valor de nice do processo (\fBnice\fP(2), \fBsetpriority\fP(2)) e
alterar o valor de nice para processos arbitrários;
.IP \[bu]
definir políticas de agendamento em tempo real para chamar processos e
definir políticas e prioridades de agendamento para processos arbitrários
(\fBsched_setscheduler\fP(2), \fBsched_setparam\fP(2), \fBsched_setattr\fP(2));
.IP \[bu]
definir afinidade de CPU para processos arbitrários
(\fBsched_setaffinity\fP(2));
.IP \[bu]
definir classe de agendamento de E/S e prioridade para processos arbitrários
(\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.
aplicar \fBmigrate_pages\fP(2) a processos arbitrários e permitir que processos
sejam migrados para nós arbitrários;
.IP \[bu]
aplicar \fBmove_pages\fP(2) a processos arbitrários;
.IP \[bu]
usar o sinalizador \fBMPOL_MF_MOVE_ALL\fP com \fBmbind\fP(2) e \fBmove_pages\fP(2).
.RE
.PD
.TP 
\fBCAP_SYS_PACCT\fP
Usar \fBacct\fP(2).
.TP 
\fBCAP_SYS_PTRACE\fP
.PD 0
.RS
.IP \[bu] 3
Rastrear processos arbitrários usando \fBptrace\fP(2);
.IP \[bu]
aplicar \fBget_robust_list\fP(2) a processos arbitrários;
.IP \[bu]
transferir dados de ou para a memória de processos arbitrários usando
\fBprocess_vm_readv\fP(2) e \fBprocess_vm_writev\fP(2);
.IP \[bu]
inspecionar processos usando \fBkcmp\fP(2).
.RE
.PD
.TP 
\fBCAP_SYS_RAWIO\fP
.PD 0
.RS
.IP \[bu] 3
Executar operações de E/S de porta (\fBiopl\fP(2) e \fBioperm\fP(2));
.IP \[bu]
acessar \fI/proc/kcore\fP;
.IP \[bu]
empregar a operação \fBFIBMAP\fP \fBioctl\fP(2);
.IP \[bu]
abrir dispositivos para acessar registradores específicos do modelo x86
(MSRs, veja \fBmsr\fP(4));
.IP \[bu]
atualizar \fI/proc/sys/vm/mmap_min_addr\fP;
.IP \[bu]
criar mapeamentos de memória em endereços abaixo do valor especificado por
\fI/proc/sys/vm/mmap_min_addr\fP;
.IP \[bu]
mapear arquivos em \fI/proc/bus/pci\fP;
.IP \[bu]
abrir \fI/dev/mem\fP e \fI/dev/kmem\fP;
.IP \[bu]
executar vários comandos de dispositivo SCSI;
.IP \[bu]
executar certas operações em dispositivos \fBhpsa\fP(4) e \fBcciss\fP(4);
.IP \[bu]
executar uma série de operações específicas de dispositivo em outros
dispositivos.
.RE
.PD
.TP 
\fBCAP_SYS_RESOURCE\fP
.PD 0
.RS
.IP \[bu] 3
Usar espaço reservado em sistemas de arquivos ext2;
.IP \[bu]
fazer chamadas \fBioctl\fP(2) controlando a manipulação do journal de ext3;
.IP \[bu]
substituir limites de cota de disco;
.IP \[bu]
aumentar limites de recursos (veja \fBsetrlimit\fP(2));
.IP \[bu]
substituir limite de recurso \fBRLIMIT_NPROC\fP;
.IP \[bu]
substituir número máximo de consoles na alocação de console;
.IP \[bu]
substituir número máximo de mapas de teclas;
.IP \[bu]
permitir interrupções com mais de 64hz do relógio de tempo real;
.IP \[bu]
aumentar o limite de \fImsg_qbytes\fP para uma fila de mensagens do System V
acima do limite em \fI/proc/sys/kernel/msgmnb\fP (consulte \fBmsgop\fP(2) e
\fBmsgctl\fP(2));
.IP \[bu]
permitir que o limite de recurso \fBRLIMIT_NOFILE\fP no número de descritores
de arquivo, durante seu uso, seja ignorado ao passar descritores de arquivo
para outro processo por meio de um soquete de domínio UNIX (consulte
\fBunix\fP(7));
.IP \[bu]
substituir o limite de \fI/proc/sys/fs/pipe\-size\-max\fP ao definir a capacidade
de um pipe usando o comando \fBF_SETPIPE_SZ\fP \fBfcntl\fP(2);
.IP \[bu]
usar \fBF_SETPIPE_SZ\fP para aumentar a capacidade de um pipe acima do limite
especificado por \fI/proc/sys/fs/pipe\-max\-size\fP;
.IP \[bu]
substituir os limites \fI/proc/sys/fs/mqueue/queues_max\fP,
\fI/proc/sys/fs/mqueue/msg_max\fP e \fI/proc/sys/fs/mqueue/msgsize_max\fP ao criar
filas de mensagens POSIX (consulte \fBmq_overview\fP(7));
.IP \[bu]
empregar a operação \fBprctl\fP(2) \fBPR_SET_MM\fP;
.IP \[bu]
definir \fI/proc/\fPpid\fI/oom_score_adj\fP para um valor menor que o último valor
definido por um processo com \fBCAP_SYS_RESOURCE\fP.
.RE
.PD
.TP 
\fBCAP_SYS_TIME\fP
Definir o relógio do sistema (\fBsettimeofday\fP(2), \fBstime\fP(2),
\fBadjtimex\fP(2)); definir relógio de tempo real (hardware).
.TP 
\fBCAP_SYS_TTY_CONFIG\fP
Usar \fBvhangup\fP(2); empregar várias operações privilegiadas \fBioctl\fP(2) em
terminais virtuais.
.TP 
\fBCAP_SYSLOG\fP (desde o Linux 2.6.37)
.RS
.PD 0
.IP \[bu] 3
Executar operações privilegiadas \fBsyslog\fP(2). Consulte \fBsyslog\fP(2) para
obter informações sobre quais operações exigem privilégio.
.IP \[bu]
Exibir endereços do kernel expostos via \fI/proc\fP e outras interfaces quando
\fI/proc/sys/kernel/kptr_restrict\fP tiver o valor 1. (Consulte a discussão
sobre \fIkptr_restrict\fP em \fBproc\fP(5).)
.PD
.RE
.TP 
\fBCAP_WAKE_ALARM\fP (desde o Linux 3.0)
.\"
Disparar algo que despertará o sistema (definir temporizadores
\fBCLOCK_REALTIME_ALARM\fP e \fBCLOCK_BOOTTIME_ALARM\fP).
.SS "Implementação passada e atual"
Uma implementação completa de capacidades requer que:
.IP \[bu] 3
Para todas as operações privilegiadas, o kernel deve verificar se a thread
tem a capacidade necessária em seu conjunto efetivo.
.IP \[bu]
O kernel deve fornecer chamadas de sistema permitindo que os conjuntos de
capacidades de uma thread sejam alteradas e recuperadas.
.IP \[bu]
O sistema de arquivos deve oferecer suporte a anexar capacidades a um
arquivo executável, para que um processo ganhe essas capacidades quando o
arquivo for executado.
.P
.\"
Antes do Linux 2.6.24, apenas os dois primeiros desses requisitos são
atendidos; desde o Linux 2.6.24, todos os três requisitos são atendidos.
.SS "Notas para desenvolvedores do kernel"
Ao adicionar um novo recurso do kernel que deve ser governado por uma
capacidade, considere os seguintes pontos.
.IP \[bu] 3
O objetivo das capacidades é dividir o poder do superusuário em partes, de
modo que se um programa que tem uma ou mais capacidades for comprometido,
seu poder de causar danos ao sistema seria menor do que o mesmo programa em
execução com privilégio de root.
.IP \[bu]
Você tem a opção de criar uma nova capacidade para seu novo recurso ou
associar o recurso a uma das capacidades existentes. Para manter o conjunto
de capacidades em um tamanho administrável, a última opção é preferível, a
menos que haja razões convincentes para escolher a primeira opção. (Há
também um limite técnico: o tamanho dos conjuntos de capacidades é
atualmente limitado a 64 bits.)
.IP \[bu]
Para determinar qual capacidade existente pode ser melhor associada ao seu
novo recurso, revise a lista de capacidades acima para encontrar um "silo"
no qual seu novo recurso se encaixe melhor. Uma abordagem a ser tomada é
determinar se há outras funções que exigem capacidades que sempre serão
usadas junto com o novo recurso. Se o novo recurso for inútil sem essas
outras funções, você deve usar a mesma capacidade que as outras funções.
.IP \[bu]
\fINão\fP escolha \fBCAP_SYS_ADMIN\fP se você puder evitá\-la! Uma grande proporção
de verificações de capacidade existentes está associada a essa capacidade
(veja a lista parcial acima). Ela pode ser plausivelmente chamada de "o novo
root", já que, por um lado, confere uma ampla gama de poderes e, por outro
lado, seu amplo escopo significa que essa é a capacidade necessária para
muitos programas privilegiados. Não piore o problema. As únicas novas
funções que devem ser associadas a \fBCAP_SYS_ADMIN\fP são aquelas que \fIquase\fP
correspondo aos usos existentes naquele silo.
.IP \[bu]
.\"
Se você determinou que é realmente necessário criar uma nova capacidade para
seu recurso, não a crie ou nomeie como uma capacidade de "uso único". Assim,
por exemplo, a adição do \fBCAP_SYS_PACCT\fP altamente específico provavelmente
foi um erro. Em vez disso, tente identificar e nomear sua nova capacidade
como um silo mais amplo no qual outros casos de uso futuros relacionados
podem se encaixar.
.SS "Conjuntos de capacidades de thread"
Cada thread tem os seguintes conjuntos de capacidade contendo zero ou mais
das capacidades acima:
.TP 
\fIPermitted\fP
Este é um superconjunto limitante para as capacidades efetivas que a thread
pode assumir. Também é um superconjunto limitante para as capacidades que
podem ser adicionadas ao conjunto herdável por uma thread que não tem a
capacidade \fBCAP_SETPCAP\fP em seu conjunto efetivo.
.IP
Se uma thread remover uma capacidade de seu conjunto permitido, ela nunca
poderá readquirir essa capacidade (a menos que seja usado \fBexecve\fP(2) por
um programa set\-user\-ID\-root ou um programa cujas capacidades de arquivo
associadas concedam essa capacidade).
.TP 
\fIInheritable\fP
Este é um conjunto de capacidades preservadas em um
\fBexecve\fP(2). Capacidades herdáveis (em inglês, "inheritable") ​​permanecem
herdáveis ​​ao executar qualquer programa, e capacidades herdáveis ​​são
adicionadas ao conjunto permitido ao executar um programa que tem os bits
correspondentes definidos no conjunto herdável do arquivo.
.IP
Como as capacidades herdáveis ​​geralmente não são preservadas em
\fBexecve\fP(2) ao executar como um usuário não root, os aplicativos que
desejam executar programas auxiliares com capacidades elevadas devem
considerar o uso de capacidades ambientais, descritas abaixo.
.TP 
\fIEffective\fP
Este é o conjunto de capacidades usado pelo kernel para executar
verificações de permissão para a thread.
.TP 
\fIBounding\fP (por cada thread desde o Linux 2.6.25)
O conjunto de limites de capacidade é um mecanismo que pode ser usado para
limitar as capacidades obtidas durante \fBexecve\fP(2).
.IP
Desde o Linux 2.6.25, este é um conjunto de capacidades por thread. Em
kernels mais antigos, o conjunto de limites de capacidade era um atributo de
todo o sistema compartilhado por todas as threads no sistema.
.IP
Para mais detalhes, veja \fIConjunto limitador de capacidades\fP abaixo.
.TP 
\fIAmbient\fP (desde o Linux 4.3)
.\" commit 58319057b7847667f0c9585b9de0e8932b0fdb08
Este é um conjunto de capacidades que são preservadas em um \fBexecve\fP(2) de
um programa que não é privilegiado. O conjunto de capacidades de ambiente
obedece à invariante de que nenhuma capacidade pode ser ambiente se não for
permitida e herdável.
.IP
O conjunto de capacidades de ambiente pode ser modificado diretamente usando
\fBprctl\fP(2). As capacidades de ambiente são automaticamente reduzidas se
qualquer uma das capacidades permitidas ou herdáveis ​​correspondentes for
reduzida.
.IP
Executar um programa que altera UID ou GID devido aos bits set\-user\-ID ou
set\-group\-ID ou executar um programa que tem qualquer conjunto de
capacidades de arquivo limpará o conjunto de ambiente. As capacidades de
ambiente são adicionadas ao conjunto permitido e atribuídas ao conjunto
efetivo quando \fBexecve\fP(2) é chamado. Se as capacidades ambientais fizerem
com que as capacidades permitidas e efetivas de um processo aumentem durante
um \fBexecve\fP(2), isso não aciona o modo de execução segura descrito em
\fBld.so\fP(8).
.P
Um filho criado via \fBfork\fP(2) herda cópias dos conjuntos de capacidades de
seu pai. Para detalhes sobre como \fBexecve\fP(2) afeta as capacidades, veja
\fITransformação de capacidades durante execve()\fP abaixo.
.P
Usando \fBcapset\fP(2), uma thread pode manipular seus próprios conjuntos de
capacidades; veja \fIAjustando conjuntos de capacidades programaticamente\fP
abaixo.
.P
.\" commit 73efc0394e148d0e15583e13712637831f926720
.\"
Desde o Linux 3.2, o arquivo \fI/proc/sys/kernel/cap_last_cap\fP expõe o valor
numérico da capacidade mais alta suportada pelo kernel em execução; isso
pode ser usado para determinar o bit mais alto que pode ser definido em um
conjunto de capacidades.
.SS "Capacidades de arquivo"
Desde o Linux 2.6.24, o kernel oferece suporte à associação de conjuntos de
capacidades com um arquivo executável usando \fBsetcap\fP(8). Os conjuntos de
capacidade de arquivo são armazenados em um atributo estendido (veja
\fBsetxattr\fP(2) e \fBxattr\fP(7)) chamado \fIsecurity.capability\fP. Escrever neste
atributo estendido requer a capacidade \fBCAP_SETFCAP\fP. Os conjuntos de
capacidade de arquivo, em conjunto com os conjuntos de capacidade do thread,
determinam as capacidades de uma thread após um \fBexecve\fP(2).
.P
Os três conjuntos de capacidades de arquivo são:
.TP 
\fIPermitted\fP (anteriormente conhecido como \fIforced\fP):
Estas capacidades são automaticamente permitidas para a thread,
independentemente das capacidades herdáveis ​​da thread.
.TP 
\fIInheritable\fP (anteriormente conhecido como \fIallowed\fP):
Este conjunto comparado em E lógico com o conjunto herdável da thread para
determinar quais capacidades herdáveis ​​são habilitadas no conjunto
permitido da thread após o \fBexecve\fP(2).
.TP 
\fIEffective\fP:
Este não é um conjunto, mas apenas um único bit. Se este bit for definido,
então durante um \fBexecve\fP(2) todas as novas capacidades permitidas para a
thread também são levantadas no conjunto efetivo. Se este bit não for
definido, então após um \fBexecve\fP(2), nenhuma das novas capacidades
permitidas está no novo conjunto efetivo.
.IP
.\"
Habilitar o bit de capacidade efetiva do arquivo implica que qualquer
capacidade permitida ou herdável do arquivo que faça com que uma thread
adquira a capacidade permitida correspondente durante um \fBexecve\fP(2) (veja
\fITransformação de capacidades durante execve()\fP abaixo) também adquirirá
essa capacidade em seu conjunto efetivo. Portanto, ao atribuir capacidades a
um arquivo (\fBsetcap\fP(8), \fBcap_set_file\fP(3), \fBcap_set_fd\fP(3)), se
especificarmos o sinalizador efetivo como habilitado para qualquer
capacidade, então o sinalizador efetivo também deve ser especificado como
habilitado para todas as outras capacidades para as quais o sinalizador
permitido ou herdável correspondente está habilitado.
.SS "Versão de atributo estendida de capacidade de arquivo"
Para permitir extensibilidade, o kernel oferece suporte a um esquema para
codificar um número de versão dentro do atributo estendido
\fIsecurity.capability\fP que é usado para implementar recursos de
arquivo. Esses números de versão são internos à implementação e não são
diretamente visíveis para aplicativos de espaço do usuário. Até o momento,
as seguintes versões são suportadas:
.TP 
\fBVFS_CAP_REVISION_1\fP
Esta foi a implementação original da capacidade de arquivo, que suportava
máscaras de 32 bits para capacidades de arquivo.
.TP 
\fBVFS_CAP_REVISION_2\fP (desde o Linux 2.6.25)
.\" commit e338d263a76af78fe8f38a72131188b58fceb591
Esta versão permite máscaras de capacidade de arquivo com tamanho de 64 bits
e foi necessária à medida que o número de capacidades suportadas cresceu
além de 32. O kernel continua a oferecer suporte transparente à execução de
arquivos que têm máscaras de capacidade de versão 1 de 32 bits, mas ao
adicionar capacidades a arquivos que não tinham capacidades anteriormente,
ou modificar as capacidades de arquivos existentes, ele usa automaticamente
o esquema da versão 2 (ou possivelmente o esquema da versão 3, conforme
descrito abaixo).
.TP 
\fBVFS_CAP_REVISION_3\fP (desde o Linux 4.14)
.\" commit 8db6c34f1dbc8e06aa016a9b829b06902c3e1340
Os recursos de arquivo da versão 3 são fornecidos para oferecer suporte a
recursos de arquivo com espaço de nomes (descritos abaixo).
.IP
Assim como com os recursos de arquivo da versão 2, as máscaras de recursos
da versão 3 têm 64 bits de tamanho. Mas, além disso, o ID do usuário raiz do
espaço de nomes é codificado no atributo estendido
\fIsecurity.capability\fP. (O ID do usuário raiz de um espaço de nomes é o
valor que o ID do usuário 0 dentro desse espaço de nomes mapeia no espaço de
nomes do usuário inicial.)
.IP
Os recursos de arquivo da versão 3 são projetados para coexistir com os
recursos da versão 2; ou seja, em um sistema Linux moderno, pode haver
alguns arquivos com recursos da versão 2, enquanto outros têm recursos da
versão 3.
.P
Antes do Linux 4.14, o único tipo de atributo estendido de capacidade de
arquivo que podia ser anexado a um arquivo era um atributo
\fBVFS_CAP_REVISION_2\fP. Desde o Linux 4.14, a versão do atributo estendido
\fIsecurity.capability\fP que é anexado a um arquivo depende das circunstâncias
em que o atributo foi criado.
.P
A partir do Linux 4.14, um atributo estendido \fIsecurity.capability\fP é
criado automaticamente como (ou convertido para) um atributo da versão 3
(\fBVFS_CAP_REVISION_3\fP) se ambas as condições a seguir forem verdadeiras:
.IP \[bu] 3
A thread que escreve o atributo reside em um espaço de nomes de usuário não
inicial. (Mais precisamente: a thread reside em um espaço de nomes de
usuário diferente daquele do qual o sistema de arquivos subjacente foi
montado.)
.IP \[bu]
A thread tem a capacidade \fBCAP_SETFCAP\fP sobre o inode do arquivo, o que
significa que (a) a thread tem a capacidade \fBCAP_SETFCAP\fP em seu próprio
espaço de nomes de usuário; e (b) o UID e o GID do inode do arquivo têm
mapeamentos no espaço de nomes de usuário de escrita.
.P
Quando um atributo estendido \fIsecurity.capability\fP de \fBVFS_CAP_REVISION_3\fP
é criado, o ID do usuário raiz do espaço de nomes do usuário da thread de
criação é salvo no atributo estendido.
.P
Por outro lado, criar ou modificar um atributo estendido
\fIsecurity.capability\fP de uma thread privilegiada (\fBCAP_SETFCAP\fP) que
reside no espaço de nomes onde o sistema de arquivos subjacente foi montado
(isso normalmente significa o espaço de nomes do usuário inicial) resulta
automaticamente na criação de um atributo da versão 2
(\fBVFS_CAP_REVISION_2\fP).
.P
Observe que a criação de um atributo estendido \fIsecurity.capability\fP versão
3 é automática. Ou seja, quando um aplicativo de espaço de usuário grava
(\fBsetxattr\fP(2)) um atributo \fIsecurity.capability\fP no formato da versão 2,
o kernel criará automaticamente um atributo da versão 3 se o atributo for
criado nas circunstâncias descritas acima. Correspondentemente, quando um
atributo \fIsecurity.capability\fP versão 3 é recuperado (\fBgetxattr\fP(2)) por
um processo que reside dentro de um espaço de nomes de usuário que foi
criado pelo ID do usuário raiz (ou um descendente desse espaço de nomes de
usuário), o atributo retornado é (automaticamente) simplificado para
aparecer como um atributo da versão 2 (ou seja, o valor retornado é o
tamanho de um atributo da versão 2 e não inclui o ID do usuário raiz). Essas
traduções automáticas significam que nenhuma alteração é necessária nas
ferramentas do espaço do usuário (por exemplo, \fBsetcap\fP(1) e \fBgetcap\fP(1))
para que essas ferramentas sejam usadas para criar e recuperar atributos
\fIsecurity.capability\fP da versão 3.
.P
.\"
Observe que um arquivo pode ter um atributo estendido \fIsecurity.capability\fP
versão 2 ou 3 associado a ele, mas não ambos: a criação ou modificação do
atributo estendido \fIsecurity.capability\fP modificará automaticamente a
versão de acordo com as circunstâncias em que o atributo estendido for
criado ou modificado.
.SS "Transformação de capacidades durante execve()"
Durante um \fBexecve\fP(2), o kernel calcula as novas capacidades do processo
usando o seguinte algoritmo:
.P
.in +4n
.EX
P'(ambient)     = (arquivo é privilegiado) ? 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)    [isto é, inalterado]
\&
P'(bounding)    = P(bounding)       [isto é, inalterado]
.EE
.in
.P
onde:
.RS 4
.TP 
P()
denota o valor de um conjunto de capacidades de thread antes de \fBexecve\fP(2)
.TP 
P'()
denota o valor de um conjunto de capacidades de thread depois de
\fBexecve\fP(2)
.TP 
F()
denota um conjunto de capacidades de arquivo
.RE
.P
Observe os seguintes detalhes relacionados às regras de transformação de
capacidades acima:
.IP \[bu] 3
O conjunto de capacidades de ambiente está presente somente desde o Linux
4.3. Ao determinar a transformação do conjunto de ambiente durante
\fBexecve\fP(2), um arquivo privilegiado é aquele que tem capacidades ou tem o
bit set\-user\-ID ou set\-group\-ID definido.
.IP \[bu]
Antes do Linux 2.6.25, o conjunto limitador era um atributo de todo o
sistema compartilhado por todas as threads. Esse valor de todo o sistema foi
empregado para calcular o novo conjunto permitido durante \fBexecve\fP(2) da
mesma maneira mostrada acima para \fIP(bounding)\fP.
.P
\fINota\fP: durante as transições de capacidade descritas acima, as capacidades
de arquivo podem ser ignoradas (tratadas como vazias) pelos mesmos motivos
que os bits set\-user\-ID e set\-group\-ID são ignorados; consulte
\fBexecve\fP(2). As capacidades de arquivo são ignoradas de forma semelhante se
o kernel foi inicializado com a opção \fIno_file_caps\fP.
.P
.\"
\fINota\fP: de acordo com as regras acima, se um processo com IDs de usuário
diferentes de zero executar um \fBexecve\fP(2), quaisquer capacidades que
estejam presentes em seus conjuntos permitidos e efetivos serão limpas. Para
o tratamento de capacidades quando um processo com uma ID de usuário zero
executa um \fBexecve\fP(2), consulte \fICapacidades e execução de programas pelo root\fP abaixo.
.SS "Verificação de segurança para binários sem suporte a capacidades"
Um binário sem suporte a capacidades é um aplicativo que foi marcado para
ter capacidades de arquivo, mas não foi convertido para usar a API
\fBlibcap\fP(3) para manipular suas capacidades. (Em outras palavras, este é um
programa tradicional set\-user\-ID\-root que foi alternado para usar recursos
de arquivo, mas cujo código não foi modificado para entender os recursos.)
Para tais aplicativos, o bit de capacidade efetiva é definido no arquivo, de
modo que os recursos permitidos do arquivo sejam habilitados automaticamente
no conjunto efetivo do processo ao executar o arquivo. O kernel reconhece um
arquivo que tem o bit de capacidade efetiva definido como não tendo suporte
a capacidades para o propósito da verificação descrita aqui.
.P
.\"
Ao executar um binário sem suporte a capacidades, o kernel verifica se o
processo obteve todos os recursos permitidos que foram especificados no
conjunto de arquivos permitidos, após as transformações de recursos
descritas acima terem sido executadas. (O motivo típico pelo qual isso pode
\fInão\fP ocorrer é que o conjunto limitador de recursos mascarou alguns dos
recursos no conjunto de arquivos permitidos.) Se o processo não obteve o
conjunto completo de recursos permitidos do arquivo, então \fBexecve\fP(2)
falha com o erro \fBEPERM\fP. Isso evita possíveis riscos de segurança que
podem surgir quando um aplicativo sem suporte a capacidades é executado com
menos privilégios do que o necessário. Observe que, por definição, o
aplicativo não poderia reconhecer esse problema, pois não emprega a API do
\fBlibcap\fP(3).
.SS "Capacidades e execução de programas pelo root"
.\" See cap_bprm_set_creds(), bprm_caps_from_vfs_cap() and
.\" handle_privileged_root() in security/commoncap.c (Linux 5.0 source)
Para espelhar a semântica tradicional do UNIX, o kernel realiza um
tratamento especial de capacidades de arquivo quando um processo com UID 0
(root) executa um programa e quando um programa set\-user\-ID\-root é
executado.
.P
Após ter realizado quaisquer alterações no ID efetivo do processo que foram
acionadas pelo bit de modo set\-user\-ID do binário \[em] por exemplo,
alternando o ID efetivo do usuário para 0 (root) porque um programa
set\-user\-ID\-root foi executado \[em] o kernel calcula os conjuntos de
capacidades de arquivo da seguinte forma:
.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)
If the effective user ID of the process is 0 (root) or the file effective
bit is in fact enabled, then the file effective bit is notionally defined to
be one (enabled).
.P
These notional values for the file's capability sets are then used as
described above to calculate the transformation of the process's
capabilities during \fBexecve\fP(2).
.P
Thus, when a process with nonzero UIDs \fBexecve\fP(2)s a set\-user\-ID\-root
program that does not have capabilities attached, or when a process whose
real and effective UIDs are zero \fBexecve\fP(2)s a program, the calculation of
the process's new permitted capabilities simplifies to:
.P
.in +4n
.EX
P'(permitted)   = P(inheritable) | P(bounding)
\&
P'(effective)   = P'(permitted)
.EE
.in
.P
Consequentemente, o processo ganha todas as capacidades em seus conjuntos de
capacidades permitidas e efetivas, exceto aquelas mascaradas pelo conjunto
limitador de capacidades. (No cálculo de P'(permitted), o termo P'(ambient)
pode ser simplificado porque é, por definição, um subconjunto próprio de
P(inheritable).)
.P
.\"
.\"
The special treatments of user ID 0 (root) described in this subsection can
be disabled using the securebits mechanism described below.
.SS "Set\-user\-ID\-root programs that have file capabilities"
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).
.P
.\"
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.
.SS "Conjunto limitador de capacidade"
O conjunto limitador de capacidade é um mecanismo de segurança que pode ser
usado para limitar as capacidades que podem ser obtidas durante um
\fBexecve\fP(2). O conjunto limitador é usado das seguintes maneiras:
.IP \[bu] 3
During an \fBexecve\fP(2), the capability bounding set is ANDed with the file
permitted capability set, and the result of this operation is assigned to
the thread's permitted capability set.  The capability bounding set thus
places a limit on the permitted capabilities that may be granted by an
executable file.
.IP \[bu]
(Since Linux 2.6.25)  The capability bounding set acts as a limiting
superset for the capabilities that a thread can add to its inheritable set
using \fBcapset\fP(2).  This means that if a capability is not in the bounding
set, then a thread can't add this capability to its inheritable set, even if
it was in its permitted capabilities, and thereby cannot have this
capability preserved in its permitted set when it \fBexecve\fP(2)s a file that
has the capability in its inheritable set.
.P
Note that the bounding set masks the file permitted capabilities, but not
the inheritable capabilities.  If a thread maintains a capability in its
inheritable set that is not in its bounding set, then it can still gain that
capability in its permitted set by executing a file that has the capability
in its inheritable set.
.P
Depending on the kernel version, the capability bounding set is either a
system\-wide attribute, or a per\-process attribute.
.P
\fBCapability bounding set from Linux 2.6.25 onward\fP
.P
From Linux 2.6.25, the \fIcapability bounding set\fP is a per\-thread
attribute.  (The system\-wide capability bounding set described below no
longer exists.)
.P
The bounding set is inherited at \fBfork\fP(2)  from the thread's parent, and
is preserved across an \fBexecve\fP(2).
.P
A thread may remove capabilities from its capability bounding set using the
\fBprctl\fP(2)  \fBPR_CAPBSET_DROP\fP operation, provided it has the
\fBCAP_SETPCAP\fP capability.  Once a capability has been dropped from the
bounding set, it cannot be restored to that set.  A thread can determine if
a capability is in its bounding set using the \fBprctl\fP(2)
\fBPR_CAPBSET_READ\fP operation.
.P
.\" 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.
.P
Removing a capability from the bounding set does not remove it from the
thread's inheritable set.  However it does prevent the capability from being
added back into the thread's inheritable set in the future.
.P
\fBCapability bounding set prior to Linux 2.6.25\fP
.P
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.)
.P
Only the \fBinit\fP process may set capabilities in the capability bounding
set; other than that, the superuser (more precisely: a process with the
\fBCAP_SYS_MODULE\fP capability) may only clear capabilities from this set.
.P
On a standard system the capability bounding set always masks out the
\fBCAP_SETPCAP\fP capability.  To remove this restriction (dangerous!), modify
the definition of \fBCAP_INIT_EFF_SET\fP in \fIinclude/linux/capability.h\fP and
rebuild the kernel.
.P
.\"
.\"
.\"
The system\-wide capability bounding set feature was added to Linux 2.2.11.
.SS "Effect of user ID changes on capabilities"
To preserve the traditional semantics for transitions between 0 and nonzero
user IDs, the kernel makes the following changes to a thread's capability
sets on changes to the thread's real, effective, saved set, and filesystem
user IDs (using \fBsetuid\fP(2), \fBsetresuid\fP(2), or similar):
.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]
If the effective user ID is changed from 0 to nonzero, then all capabilities
are cleared from the effective set.
.IP \[bu]
If the effective user ID is changed from nonzero to 0, then the permitted
set is copied to the effective set.
.IP \[bu]
If the filesystem user ID is changed from 0 to nonzero (see \fBsetfsuid\fP(2)),
then the following capabilities are cleared from the effective set:
\fBCAP_CHOWN\fP, \fBCAP_DAC_OVERRIDE\fP, \fBCAP_DAC_READ_SEARCH\fP, \fBCAP_FOWNER\fP,
\fBCAP_FSETID\fP, \fBCAP_LINUX_IMMUTABLE\fP (since Linux 2.6.30),
\fBCAP_MAC_OVERRIDE\fP, and \fBCAP_MKNOD\fP (since Linux 2.6.30).  If the
filesystem UID is changed from nonzero to 0, then any of these capabilities
that are enabled in the permitted set are enabled in the effective set.
.P
.\"
If a thread that has a 0 value for one or more of its user IDs wants to
prevent its permitted capability set being cleared when it resets all of its
user IDs to nonzero values, it can do so using the \fBSECBIT_KEEP_CAPS\fP
securebits flag described below.
.SS "Ajustando conjuntos de capacidades programaticamente"
A thread can retrieve and change its permitted, effective, and inheritable
capability sets using the \fBcapget\fP(2)  and \fBcapset\fP(2)  system calls.
However, the use of \fBcap_get_proc\fP(3)  and \fBcap_set_proc\fP(3), both
provided in the \fIlibcap\fP package, is preferred for this purpose.  The
following rules govern changes to the thread capability sets:
.IP \[bu] 3
If the caller does not have the \fBCAP_SETPCAP\fP capability, the new
inheritable set must be a subset of the combination of the existing
inheritable and permitted sets.
.IP \[bu]
(Since Linux 2.6.25)  The new inheritable set must be a subset of the
combination of the existing inheritable set and the capability bounding set.
.IP \[bu]
The new permitted set must be a subset of the existing permitted set (i.e.,
it is not possible to acquire permitted capabilities that the thread does
not currently have).
.IP \[bu]
The new effective set must be a subset of the new permitted set.
.SS "The securebits flags: establishing a capabilities\-only environment"
.\" 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
Setting this flag allows a thread that has one or more 0 UIDs to retain
capabilities in its permitted set 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 permitted capabilities.  This flag is always cleared on
an \fBexecve\fP(2).
.IP
Note that even with the \fBSECBIT_KEEP_CAPS\fP flag set, the effective
capabilities of a thread are cleared when it switches its effective UID to a
nonzero value.  However, if the thread has set this flag and its effective
UID is already nonzero, and the thread subsequently switches all other UIDs
to nonzero values, then the effective capabilities will not be cleared.
.IP
The setting of the \fBSECBIT_KEEP_CAPS\fP flag is ignored if the
\fBSECBIT_NO_SETUID_FIXUP\fP flag is set.  (The latter flag provides a superset
of the effect of the former flag.)
.IP
This flag provides the same functionality as the older \fBprctl\fP(2)
\fBPR_SET_KEEPCAPS\fP operation.
.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
Setting this flag disallows raising ambient capabilities via the \fBprctl\fP(2)
\fBPR_CAP_AMBIENT_RAISE\fP operation.
.P
Each of the above "base" flags has a companion "locked" flag.  Setting any
of the "locked" flags is irreversible, and has the effect of preventing
further changes to the corresponding "base" flag.  The locked flags are:
\fBSECBIT_KEEP_CAPS_LOCKED\fP, \fBSECBIT_NO_SETUID_FIXUP_LOCKED\fP,
\fBSECBIT_NOROOT_LOCKED\fP, and \fBSECBIT_NO_CAP_AMBIENT_RAISE_LOCKED\fP.
.P
The \fIsecurebits\fP flags can be modified and retrieved using the \fBprctl\fP(2)
\fBPR_SET_SECUREBITS\fP and \fBPR_GET_SECUREBITS\fP operations.  The
\fBCAP_SETPCAP\fP capability is required to modify the flags.  Note that the
\fBSECBIT_*\fP constants are available only after including the
\fI<linux/securebits.h>\fP header file.
.P
The \fIsecurebits\fP flags are inherited by child processes.  During an
\fBexecve\fP(2), all of the flags are preserved, except \fBSECBIT_KEEP_CAPS\fP
which is always cleared.
.P
An application can use the following call to lock itself, and all of its
descendants, into an environment where the only way of gaining capabilities
is by executing a program with associated file capabilities:
.P
.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);
        /* Setting/locking SECBIT_NO_CAP_AMBIENT_RAISE
           is not required */
.EE
.in
.\"
.\"
.SS "Per\-user\-namespace \[dq]set\-user\-ID\-root\[dq] programs"
A set\-user\-ID program whose UID matches the UID that created a user
namespace will confer capabilities in the process's permitted and effective
sets when executed by any process inside that namespace or any descendant
user namespace.
.P
.\"
.\"
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 "Namespaced file capabilities"
.\" 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.
.P
Because version 2 file capabilities confer capabilities to the executing
process regardless of which user namespace it resides in, only privileged
processes are permitted to associate capabilities with a file.  Here,
"privileged" means a process that has the \fBCAP_SETFCAP\fP capability in the
user namespace where the filesystem was mounted (normally the initial user
namespace).  This limitation renders file capabilities useless for certain
use cases.  For example, in user\-namespaced containers, it can be desirable
to be able to create a binary that confers capabilities only to processes
executed inside that container, but not to processes that are executed
outside the container.
.P
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.
.P
.\"
.\"
As with a binary that has \fBVFS_CAP_REVISION_2\fP file capabilities, a binary
with \fBVFS_CAP_REVISION_3\fP file capabilities confers capabilities to a
process during \fBexecve\fP().  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 a descendant of such a namespace.
.SS "Interaction with user namespaces"
For further information on the interaction of capabilities and user
namespaces, see \fBuser_namespaces\fP(7).
.SH PADRÕES
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 NOTAS
When attempting to \fBstrace\fP(1)  binaries that have capabilities (or
set\-user\-ID\-root binaries), you may find the \fI\-u <username>\fP option
useful.  Something like:
.P
.in +4n
.EX
$\fB sudo strace \-o trace.log \-u ceci ./myprivprog\fP
.EE
.in
.P
.\" 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.
.P
.\" 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).
.P
The \fIlibcap\fP package provides a suite of routines for setting and getting
capabilities that is more comfortable and less likely to change than the
interface provided by \fBcapset\fP(2)  and \fBcapget\fP(2).  This package also
provides the \fBsetcap\fP(8)  and \fBgetcap\fP(8)  programs.  It can be found at
.br
.UR https://git.kernel.org\:/pub\:/scm\:/libs\:/libcap\:/libcap.git\:/refs/
.UE .
.P
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 "VEJA TAMBÉM"
.\" 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)
.P
\fIinclude/linux/capability.h\fP in the Linux kernel source tree
.PP
.SH TRADUÇÃO
A tradução para português brasileiro desta página man foi criada por
Rafael Fontenelle <rafaelff@gnome.org>
.
.PP
Esta tradução é uma documentação livre; leia a
.UR https://www.gnu.org/licenses/gpl-3.0.html
Licença Pública Geral GNU Versão 3 
.UE
ou posterior para as condições de direitos autorais.
Nenhuma responsabilidade é aceita.
.PP
Se você encontrar algum erro na tradução desta página de manual,
envie um e-mail para
.MT debian-l10n-portuguese@lists.debian.org
a lista de discussão de tradutores
.ME .