Capacidades(7) Miscellaneous Information Manual Capacidades(7) NOME capabilities - visao geral das capacidades do Linux DESCRICAO Para fins de executar verificacoes de permissao, implementacoes UNIX tradicionais distinguem duas categorias de processos: processos privilegiados (cujo ID de usuario efetivo e 0, chamado de superusuario ou root) e processos desprivilegiados (cujo UID efetivo e diferente de zero). Processos privilegiados ignoram todas as verificacoes de permissao do kernel, enquanto processos nao privilegiados estao sujeitos a verificacao de permissao completa com base nas credenciais do processo (geralmente: UID efetivo, GID efetivo e lista de grupos suplementares). A partir do Linux 2.2, o Linux divide os privilegios tradicionalmente associados ao superusuario em unidades distintas, conhecidas como capacidades (em ingles capabilities), que podem ser habilitadas e desabilitadas independentemente. Capacidades sao um atributo por thread. Lista de capacidades A lista a seguir mostra as capacidades implementadas no Linux e as operacoes ou comportamentos que cada capacidade permite: CAP_AUDIT_CONTROL (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. CAP_AUDIT_READ (desde o Linux 3.16) Permitir leitura do log de auditoria por meio de um soquete netlink multicast. CAP_AUDIT_WRITE (desde o Linux 2.6.11) Gravar registros no log de auditoria do kernel. CAP_BLOCK_SUSPEND (desde o Linux 3.5) Empregar recursos que podem bloquear a suspensao do sistema (epoll(7) EPOLLWAKEUP, /proc/sys/wake_lock). CAP_BPF (desde o Linux 5.8) Empregar operacoes BPF privilegiadas; veja bpf(2) e bpf-helpers(7). Esta capacidade foi adicionada no Linux 5.8 para separar a funcionalidade BPF da capacidade sobrecarregada CAP_SYS_ADMIN. CAP_CHECKPOINT_RESTORE (desde o Linux 5.9) o Atualizar /proc/sys/kernel/ns_last_pid (veja pid_namespaces(7)); o empregar o recurso set_tid de clone3(2); o ler o conteudo dos links simbolicos em /proc/pid/map_files para outros processos. Esta capacidade foi adicionada no Linux 5.9 para separar a funcionalidade checkpoint/restore da capacidade sobrecarregada CAP_SYS_ADMIN. CAP_CHOWN Fazer alteracoes arbitrarias em UIDs e GIDs de arquivo (veja chown(2)). CAP_DAC_OVERRIDE Ignorar verificacoes de permissao de leitura, gravacao e execucao de arquivo. (DAC e uma abreviacao de "controle de acesso discricionario" em ingles.) CAP_DAC_READ_SEARCH o Ignorar verificacoes de permissao de leitura de arquivo e verificacoes de permissao de leitura e execucao de diretorio; o invoca open_by_handle_at(2); o usar o sinalizador linkat(2) AT_EMPTY_PATH para criar um link para um arquivo referenciado por um descritor de arquivo. CAP_FOWNER o Ignorar verificacoes de permissao em operacoes que normalmente exigem que o UID do sistema de arquivos do processo corresponda ao UID do arquivo (por exemplo, chmod(2), utime(2)), excluindo as operacoes cobertas por CAP_DAC_OVERRIDE e CAP_DAC_READ_SEARCH; o definir sinalizadores de inode (consulte FS_IOC_SETFLAGS(2const)) em arquivos arbitrarios; o definir listas de controle de acesso (ACLs) em arquivos arbitrarios; o ignorar sticky bit de diretorio na exclusao de arquivo; o modificar atributos estendidos de usuario em diretorio sticky de propriedade de qualquer usuario; o especificar O_NOATIME para arquivos arbitrarios em open(2) e fcntl(2). CAP_FSETID o Nao limpar bits de modo set-user-ID e set-group-ID quando um arquivo for modificado; o definir o bit set-group-ID para um arquivo cujo GID nao corresponde ao sistema de arquivos ou a qualquer um dos GIDs suplementares do processo de chamada. CAP_IPC_LOCK o Bloquear a memoria (mlock(2), mlockall(2), mmap(2), shmctl(2)); o Alocar memoria usando paginas enormes (memfd_create(2), mmap(2), shmctl(2)). CAP_IPC_OWNER Ignorar verificacoes de permissao para operacoes em objetos IPC do System V. CAP_KILL Ignorar verificacoes de permissao para enviar sinais (consulte kill(2)). Isso inclui o uso da operacao ioctl(2) KDSIGACCEPT. CAP_LEASE (desde o Linux 2.4) Estabelecer concessoes em arquivos arbitrarios (consulte fcntl(2)). CAP_LINUX_IMMUTABLE Definir os sinalizadores de inode FS_APPEND_FL e FS_IMMUTABLE_FL (consulte FS_IOC_SETFLAGS(2const)). CAP_MAC_ADMIN (desde o Linux 2.6.25) Permitir configuracao de MAC ou alteracoes de estado. Implementada para o Smack Linux Security Module (LSM). CAP_MAC_OVERRIDE (desde o Linux 2.6.25) Substituir o Mandatory Access Control (MAC). Implementada para o Smack LSM. CAP_MKNOD (desde o Linux 2.4) Criar arquivos especiais usando mknod(2). CAP_NET_ADMIN Executar varias operacoes relacionadas a rede: o configuracao de interface; o administracao de firewall de IP, de m e contas; o modificar tabelas de roteamento; o vincular a qualquer endereco para proxy transparente; o definir o tipo de servico (TOS); o limpar estatisticas do driver; o definir o modo promiscuo; o habilitar multicasting; o usar setsockopt(2) para definir as seguintes opcoes de soquete: SO_DEBUG, SO_MARK, SO_PRIORITY (para uma prioridade fora do intervalo de 0 a 6), SO_RCVBUFFORCE e SO_SNDBUFFORCE. CAP_NET_BIND_SERVICE Vincular um socket a portas privilegiadas de dominio da Internet (numeros de porta menores que 1024). CAP_NET_BROADCAST (Nao usado) Fazer transmissoes de socket e ouvir multicasts. CAP_NET_RAW o Usar sockets RAW e PACKET; o vincular a qualquer endereco para proxy transparente. CAP_PERFMON (desde o Linux 5.8) Empregar varios mecanismos de monitoramento de desempenho, incluindo: o chamar perf_event_open(2); o empregar varias operacoes BPF que tem implicacoes de desempenho. Esta capacidade foi adicionada no Linux 5.8 para separar a funcionalidade de monitoramento de desempenho da capacidade sobrecarregada CAP_SYS_ADMIN. Veja tambem o arquivo-fonte do kernel Documentation/admin-guide/perf-security.rst. CAP_SETGID o Fazer manipulacoes arbitrarias de GIDs de processo e listar de GID suplementar; o forjar GID ao passar credenciais de socket por meio de sockets de dominio UNIX; o escrever um mapeamento de ID de grupo em um espaco de nomes de usuario (veja user_namespaces(7)). CAP_SETFCAP (desde o Linux 2.6.24) Definir capacidades arbitrarias em um arquivo. Desde o Linux 5.12, esse recurso tambem e necessario para mapear o ID do usuario 0 em um novo espaco de nomes de usuario; veja user_namespaces(7) para detalhes. CAP_SETPCAP Se os recursos de arquivo forem suportados (isto e, desde o Linux 2.6.24): adicionar qualquer recurso do conjunto delimitador da thread de chamada ao seu conjunto herdavel; remover recursos do conjunto delimitador (por meio de prctl(2) PR_CAPBSET_DROP); fazer alteracoes nos sinalizadores securebits. Se os recursos de arquivo nao forem suportados (isto e, 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 CAP_SETPCAP nao esta disponivel quando o kernel e configurado para suportar recursos de arquivo, ja que CAP_SETPCAP tem semanticas totalmente diferentes para tais kernels.) CAP_SETUID o Fazer manipulacoes arbitrarias de UIDs de processo (setuid(2), setreuid(2), setresuid(2), setfsuid(2)); o forjar UID ao passar credenciais de soquete por meio de soquetes de dominio UNIX; o escrever um mapeamento de ID de usuario em um espaco de nomes de usuario (consulte user_namespaces(7)). CAP_SYS_ADMIN Nota: esta capacidade esta sobrecarregada; consulte Notas para desenvolvedores de kernel abaixo. o Executar uma serie de operacoes de administracao do sistema, incluindo: quotactl(2), mount(2), umount(2), pivot_root(2), swapon(2), swapoff(2), sethostname(2) e setdomainname(2); o executar operacoes privilegiadas de syslog(2) (desde o Linux 2.6.37, CAP_SYSLOG deve ser usado para permitir tais operacoes); o executar o comando VM86_REQUEST_IRQ vm86(2); o acessar a mesma funcionalidade de checkpoint/restauracao que e governada por CAP_CHECKPOINT_RESTORE (mas a ultima, capacidade mais fraca, e preferida para acessar essa funcionalidade). o executar as mesmas operacoes BPF que sao governadas por CAP_BPF (mas a ultima, capacidade mais fraca, e preferida para acessar essa funcionalidade). o empregar os mesmos mecanismos de monitoramento de desempenho que sao governados por CAP_PERFMON (mas a ultima, capacidade mais fraca, e preferida para acessar essa funcionalidade). o executar operacoes IPC_SET e IPC_RMID em objetos IPC arbitrarios do System V; o substituir limite de recurso RLIMIT_NPROC; o executar operacoes em atributos estendidos trusted e security (consulte xattr(7)); o usar lookup_dcookie(2); o usar ioprio_set(2) para atribuir classes de agendamento de E/S IOPRIO_CLASS_RT e (antes do Linux 2.6.25) IOPRIO_CLASS_IDLE; o forjar PID ao passar credenciais de soquete por soquetes de dominio UNIX; o exceder /proc/sys/fs/file-max, o limite de todo o sistema no numero de arquivos abertos, em chamadas de sistema que abrem arquivos (por exemplo, accept(2), execve(2), open(2), pipe(2)); o empregar sinalizadores CLONE_* que criam novos espacos de nomes com clone(2) e unshare(2) (mas, desde o Linux 3.8, criar espacos de nomes de usuario nao requer nenhuma capacidade); o acessar informacoes privilegiadas de eventos perf; o chamar setns(2) (requer CAP_SYS_ADMIN no espaco de nomes target); o chamar fanotify_init(2); o executar operacoes privilegiadas KEYCTL_CHOWN e KEYCTL_SETPERM do keyctl(2); o executar a operacao madvise(2) MADV_HWPOISON; o empregar o TIOCSTI ioctl(2) para inserir caracteres na fila de entrada de um terminal diferente do terminal de controle do chamador; o empregar a chamada de sistema nfsservctl(2) obsoleta; o empregar a chamada de sistema bdflush(2) obsoleta; o executar varias operacoes de dispositivo de bloco privilegiado ioctl(2); o executar varias operacoes de sistema de arquivo privilegiado ioctl(2); o executar operacoes ioctl(2) privilegiadas no dispositivo /dev/random (consulte random(4)); o instalar um filtro seccomp(2) sem primeiro ter que definir o atributo de thread no_new_privs; o modificar regras de permissao/negacao para grupos de controle de dispositivo; o empregar a operacao ptrace(2) PTRACE_SECCOMP_GET_FILTER para despejar os filtros seccomp do tracee; o empregar a operacao ptrace(2) PTRACE_SETOPTIONS para suspender as protecoes seccomp do tracee (ou seja, o sinalizador PTRACE_O_SUSPEND_SECCOMP); o executar operacoes administrativas em muitos drivers de dispositivo; o modificar valores de nice do autogroup escrevendo em /proc/pid/autogroup (consulte sched(7)). CAP_SYS_BOOT Usar reboot(2) e kexec_load(2). CAP_SYS_CHROOT o Usar chroot(2); o alterar espacos de nomes de montagem usando setns(2). CAP_SYS_MODULE o Carregar e descarregar modulos do kernel (veja init_module(2) e delete_module(2)); o antes do Linux 2.6.25: remover recursos do conjunto de delimitacao de recursos de todo o sistema. CAP_SYS_NICE o Reduzir o valor de nice do processo (nice(2), setpriority(2)) e alterar o valor de nice para processos arbitrarios; o definir politicas de agendamento em tempo real para chamar processos e definir politicas e prioridades de agendamento para processos arbitrarios (sched_setscheduler(2), sched_setparam(2), sched_setattr(2)); o definir afinidade de CPU para processos arbitrarios (sched_setaffinity(2)); o definir classe de agendamento de E/S e prioridade para processos arbitrarios (ioprio_set(2)); o aplicar migrate_pages(2) a processos arbitrarios e permitir que processos sejam migrados para nos arbitrarios; o aplicar move_pages(2) a processos arbitrarios; o usar o sinalizador MPOL_MF_MOVE_ALL com mbind(2) e move_pages(2). CAP_SYS_PACCT Usar acct(2). CAP_SYS_PTRACE o Rastrear processos arbitrarios usando ptrace(2); o inspect sensitive information of other processes via /proc (e.g., reading /proc/pid/maps, /proc/pid/mem, or reading symbolic links /proc/pid/exe, /proc/pid/fd/*); o aplicar get_robust_list(2) a processos arbitrarios; o transferir dados de ou para a memoria de processos arbitrarios usando process_vm_readv(2) e process_vm_writev(2); o inspect processes using kcmp(2); o perform other privileged process-inspection and debugging operations. (See uses of the ptrace_may_access() kernel function.) CAP_SYS_RAWIO o Executar operacoes de E/S de porta (iopl(2) e ioperm(2)); o acessar /proc/kcore; o empregar a operacao FIBMAP ioctl(2); o abrir dispositivos para acessar registradores especificos do modelo x86 (MSRs, veja msr(4)); o atualizar /proc/sys/vm/mmap_min_addr; o criar mapeamentos de memoria em enderecos abaixo do valor especificado por /proc/sys/vm/mmap_min_addr; o mapear arquivos em /proc/bus/pci; o abrir /dev/mem e /dev/kmem; o executar varios comandos de dispositivo SCSI; o executar certas operacoes em dispositivos hpsa(4) e cciss(4); o executar uma serie de operacoes especificas de dispositivo em outros dispositivos. CAP_SYS_RESOURCE o Usar espaco reservado em sistemas de arquivos ext2; o fazer chamadas ioctl(2) controlando a manipulacao do journal de ext3; o substituir limites de cota de disco; o aumentar limites de recursos (veja setrlimit(2)); o substituir limite de recurso RLIMIT_NPROC; o substituir numero maximo de consoles na alocacao de console; o substituir numero maximo de mapas de teclas; o permitir interrupcoes com mais de 64hz do relogio de tempo real; o aumentar o limite de msg_qbytes para uma fila de mensagens do System V acima do limite em /proc/sys/kernel/msgmnb (consulte msgop(2) e msgctl(2)); o permitir que o limite de recurso RLIMIT_NOFILE no numero de descritores de arquivo, durante seu uso, seja ignorado ao passar descritores de arquivo para outro processo por meio de um soquete de dominio UNIX (consulte unix(7)); o substituir o limite de /proc/sys/fs/pipe-size-max ao definir a capacidade de um pipe usando o comando F_SETPIPE_SZ fcntl(2); o usar F_SETPIPE_SZ para aumentar a capacidade de um pipe acima do limite especificado por /proc/sys/fs/pipe-max-size; o substituir os limites /proc/sys/fs/mqueue/queues_max, /proc/sys/fs/mqueue/msg_max e /proc/sys/fs/mqueue/msgsize_max ao criar filas de mensagens POSIX (consulte mq_overview(7)); o empregar a operacao prctl(2) PR_SET_MM; o definir /proc/pid/oom_score_adj para um valor menor que o ultimo valor definido por um processo com CAP_SYS_RESOURCE. CAP_SYS_TIME Definir o relogio do sistema (settimeofday(2), stime(2), adjtimex(2)); definir relogio de tempo real (hardware). CAP_SYS_TTY_CONFIG Usar vhangup(2); empregar varias operacoes privilegiadas ioctl(2) em terminais virtuais. CAP_SYSLOG (desde o Linux 2.6.37) o Executar operacoes privilegiadas syslog(2). Consulte syslog(2) para obter informacoes sobre quais operacoes exigem privilegio. o Exibir enderecos do kernel expostos via /proc e outras interfaces quando /proc/sys/kernel/kptr_restrict tiver o valor 1. (Consulte a discussao sobre kptr_restrict em proc(5).) CAP_WAKE_ALARM (desde o Linux 3.0) Disparar algo que despertara o sistema (definir temporizadores CLOCK_REALTIME_ALARM e CLOCK_BOOTTIME_ALARM). Implementacao passada e atual Uma implementacao completa de capacidades requer que: o Para todas as operacoes privilegiadas, o kernel deve verificar se a thread tem a capacidade necessaria em seu conjunto efetivo. o O kernel deve fornecer chamadas de sistema permitindo que os conjuntos de capacidades de uma thread sejam alteradas e recuperadas. o O sistema de arquivos deve oferecer suporte a anexar capacidades a um arquivo executavel, para que um processo ganhe essas capacidades quando o arquivo for executado. Antes do Linux 2.6.24, apenas os dois primeiros desses requisitos sao atendidos; desde o Linux 2.6.24, todos os tres requisitos sao atendidos. Notas para desenvolvedores do kernel Ao adicionar um novo recurso do kernel que deve ser governado por uma capacidade, considere os seguintes pontos. o O objetivo das capacidades e dividir o poder do superusuario 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 execucao com privilegio de root. o Voce tem a opcao 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 administravel, a ultima opcao e preferivel, a menos que haja razoes convincentes para escolher a primeira opcao. (Ha tambem um limite tecnico: o tamanho dos conjuntos de capacidades e atualmente limitado a 64 bits.) o 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 e determinar se ha outras funcoes que exigem capacidades que sempre serao usadas junto com o novo recurso. Se o novo recurso for inutil sem essas outras funcoes, voce deve usar a mesma capacidade que as outras funcoes. o Nao escolha CAP_SYS_ADMIN se voce puder evita-la! Uma grande proporcao de verificacoes de capacidade existentes esta associada a essa capacidade (veja a lista parcial acima). Ela pode ser plausivelmente chamada de "o novo root", ja que, por um lado, confere uma ampla gama de poderes e, por outro lado, seu amplo escopo significa que essa e a capacidade necessaria para muitos programas privilegiados. Nao piore o problema. As unicas novas funcoes que devem ser associadas a CAP_SYS_ADMIN sao aquelas que quase correspondo aos usos existentes naquele silo. o Se voce determinou que e realmente necessario criar uma nova capacidade para seu recurso, nao a crie ou nomeie como uma capacidade de "uso unico". Assim, por exemplo, a adicao do CAP_SYS_PACCT altamente especifico 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. Conjuntos de capacidades de thread Cada thread tem os seguintes conjuntos de capacidade contendo zero ou mais das capacidades acima: Permitted Este e um superconjunto limitante para as capacidades efetivas que a thread pode assumir. Tambem e um superconjunto limitante para as capacidades que podem ser adicionadas ao conjunto herdavel por uma thread que nao tem a capacidade CAP_SETPCAP em seu conjunto efetivo. Se uma thread remover uma capacidade de seu conjunto permitido, ela nunca podera readquirir essa capacidade (a menos que seja usado execve(2) por um programa set-user-ID-root ou um programa cujas capacidades de arquivo associadas concedam essa capacidade). Inheritable Este e um conjunto de capacidades preservadas em um execve(2). Capacidades herdaveis (em ingles, "inheritable") permanecem herdaveis ao executar qualquer programa, e capacidades herdaveis sao adicionadas ao conjunto permitido ao executar um programa que tem os bits correspondentes definidos no conjunto herdavel do arquivo. Como as capacidades herdaveis geralmente nao sao preservadas em execve(2) ao executar como um usuario nao root, os aplicativos que desejam executar programas auxiliares com capacidades elevadas devem considerar o uso de capacidades ambientais, descritas abaixo. Effective Este e o conjunto de capacidades usado pelo kernel para executar verificacoes de permissao para a thread. Bounding (por cada thread desde o Linux 2.6.25) O conjunto de limites de capacidade e um mecanismo que pode ser usado para limitar as capacidades obtidas durante execve(2). Desde o Linux 2.6.25, este e 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. Para mais detalhes, veja Conjunto limitador de capacidades abaixo. Ambient (desde o Linux 4.3) Este e um conjunto de capacidades que sao preservadas em um execve(2) de um programa que nao e privilegiado. O conjunto de capacidades de ambiente obedece a invariante de que nenhuma capacidade pode ser ambiente se nao for permitida e herdavel. O conjunto de capacidades de ambiente pode ser modificado diretamente usando prctl(2). As capacidades de ambiente sao automaticamente reduzidas se qualquer uma das capacidades permitidas ou herdaveis correspondentes for reduzida. 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 limpara o conjunto de ambiente. As capacidades de ambiente sao adicionadas ao conjunto permitido e atribuidas ao conjunto efetivo quando execve(2) e chamado. Se as capacidades ambientais fizerem com que as capacidades permitidas e efetivas de um processo aumentem durante um execve(2), isso nao aciona o modo de execucao segura descrito em ld.so(8). Um filho criado via fork(2) herda copias dos conjuntos de capacidades de seu pai. Para detalhes sobre como execve(2) afeta as capacidades, veja Transformacao de capacidades durante execve() abaixo. Usando capset(2), uma thread pode manipular seus proprios conjuntos de capacidades; veja Ajustando conjuntos de capacidades programaticamente abaixo. Desde o Linux 3.2, o arquivo /proc/sys/kernel/cap_last_cap expoe o valor numerico da capacidade mais alta suportada pelo kernel em execucao; isso pode ser usado para determinar o bit mais alto que pode ser definido em um conjunto de capacidades. Capacidades de arquivo Desde o Linux 2.6.24, o kernel oferece suporte a associacao de conjuntos de capacidades com um arquivo executavel usando setcap(8). Os conjuntos de capacidade de arquivo sao armazenados em um atributo estendido (veja setxattr(2) e xattr(7)) chamado security.capability. Escrever neste atributo estendido requer a capacidade CAP_SETFCAP. Os conjuntos de capacidade de arquivo, em conjunto com os conjuntos de capacidade do thread, determinam as capacidades de uma thread apos um execve(2). Os tres conjuntos de capacidades de arquivo sao: Permitted (anteriormente conhecido como forced): Estas capacidades sao automaticamente permitidas para a thread, independentemente das capacidades herdaveis da thread. Inheritable (anteriormente conhecido como allowed): Este conjunto comparado em E logico com o conjunto herdavel da thread para determinar quais capacidades herdaveis sao habilitadas no conjunto permitido da thread apos o execve(2). Effective: Este nao e um conjunto, mas apenas um unico bit. Se este bit for definido, entao durante um execve(2) todas as novas capacidades permitidas para a thread tambem sao levantadas no conjunto efetivo. Se este bit nao for definido, entao apos um execve(2), nenhuma das novas capacidades permitidas esta no novo conjunto efetivo. Habilitar o bit de capacidade efetiva do arquivo implica que qualquer capacidade permitida ou herdavel do arquivo que faca com que uma thread adquira a capacidade permitida correspondente durante um execve(2) (veja Transformacao de capacidades durante execve() abaixo) tambem adquirira essa capacidade em seu conjunto efetivo. Portanto, ao atribuir capacidades a um arquivo (setcap(8), cap_set_file(3), cap_set_fd(3)), se especificarmos o sinalizador efetivo como habilitado para qualquer capacidade, entao o sinalizador efetivo tambem deve ser especificado como habilitado para todas as outras capacidades para as quais o sinalizador permitido ou herdavel correspondente esta habilitado. Versao de atributo estendida de capacidade de arquivo Para permitir extensibilidade, o kernel oferece suporte a um esquema para codificar um numero de versao dentro do atributo estendido security.capability que e usado para implementar recursos de arquivo. Esses numeros de versao sao internos a implementacao e nao sao diretamente visiveis para aplicativos de espaco do usuario. Ate o momento, as seguintes versoes sao suportadas: VFS_CAP_REVISION_1 Esta foi a implementacao original da capacidade de arquivo, que suportava mascaras de 32 bits para capacidades de arquivo. VFS_CAP_REVISION_2 (desde o Linux 2.6.25) Esta versao permite mascaras de capacidade de arquivo com tamanho de 64 bits e foi necessaria a medida que o numero de capacidades suportadas cresceu alem de 32. O kernel continua a oferecer suporte transparente a execucao de arquivos que tem mascaras de capacidade de versao 1 de 32 bits, mas ao adicionar capacidades a arquivos que nao tinham capacidades anteriormente, ou modificar as capacidades de arquivos existentes, ele usa automaticamente o esquema da versao 2 (ou possivelmente o esquema da versao 3, conforme descrito abaixo). VFS_CAP_REVISION_3 (desde o Linux 4.14) Os recursos de arquivo da versao 3 sao fornecidos para oferecer suporte a recursos de arquivo com espaco de nomes (descritos abaixo). Assim como com os recursos de arquivo da versao 2, as mascaras de recursos da versao 3 tem 64 bits de tamanho. Mas, alem disso, o ID do usuario raiz do espaco de nomes e codificado no atributo estendido security.capability. (O ID do usuario raiz de um espaco de nomes e o valor que o ID do usuario 0 dentro desse espaco de nomes mapeia no espaco de nomes do usuario inicial.) Os recursos de arquivo da versao 3 sao projetados para coexistir com os recursos da versao 2; ou seja, em um sistema Linux moderno, pode haver alguns arquivos com recursos da versao 2, enquanto outros tem recursos da versao 3. Antes do Linux 4.14, o unico tipo de atributo estendido de capacidade de arquivo que podia ser anexado a um arquivo era um atributo VFS_CAP_REVISION_2. Desde o Linux 4.14, a versao do atributo estendido security.capability que e anexado a um arquivo depende das circunstancias em que o atributo foi criado. A partir do Linux 4.14, um atributo estendido security.capability e criado automaticamente como (ou convertido para) um atributo da versao 3 (VFS_CAP_REVISION_3) se ambas as condicoes a seguir forem verdadeiras: o A thread que escreve o atributo reside em um espaco de nomes de usuario nao inicial. (Mais precisamente: a thread reside em um espaco de nomes de usuario diferente daquele do qual o sistema de arquivos subjacente foi montado.) o A thread tem a capacidade CAP_SETFCAP sobre o inode do arquivo, o que significa que (a) a thread tem a capacidade CAP_SETFCAP em seu proprio espaco de nomes de usuario; e (b) o UID e o GID do inode do arquivo tem mapeamentos no espaco de nomes de usuario de escrita. Quando um atributo estendido security.capability de VFS_CAP_REVISION_3 e criado, o ID do usuario raiz do espaco de nomes do usuario da thread de criacao e salvo no atributo estendido. Por outro lado, criar ou modificar um atributo estendido security.capability de uma thread privilegiada (CAP_SETFCAP) que reside no espaco de nomes onde o sistema de arquivos subjacente foi montado (isso normalmente significa o espaco de nomes do usuario inicial) resulta automaticamente na criacao de um atributo da versao 2 (VFS_CAP_REVISION_2). Observe que a criacao de um atributo estendido security.capability versao 3 e automatica. Ou seja, quando um aplicativo de espaco de usuario grava (setxattr(2)) um atributo security.capability no formato da versao 2, o kernel criara automaticamente um atributo da versao 3 se o atributo for criado nas circunstancias descritas acima. Correspondentemente, quando um atributo security.capability versao 3 e recuperado (getxattr(2)) por um processo que reside dentro de um espaco de nomes de usuario que foi criado pelo ID do usuario raiz (ou um descendente desse espaco de nomes de usuario), o atributo retornado e (automaticamente) simplificado para aparecer como um atributo da versao 2 (ou seja, o valor retornado e o tamanho de um atributo da versao 2 e nao inclui o ID do usuario raiz). Essas traducoes automaticas significam que nenhuma alteracao e necessaria nas ferramentas do espaco do usuario (por exemplo, setcap(1) e getcap(1)) para que essas ferramentas sejam usadas para criar e recuperar atributos security.capability da versao 3. Observe que um arquivo pode ter um atributo estendido security.capability versao 2 ou 3 associado a ele, mas nao ambos: a criacao ou modificacao do atributo estendido security.capability modificara automaticamente a versao de acordo com as circunstancias em que o atributo estendido for criado ou modificado. Transformacao de capacidades durante execve() Durante um execve(2), o kernel calcula as novas capacidades do processo usando o seguinte algoritmo: P'(ambient) = (arquivo e 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 e, inalterado] P'(bounding) = P(bounding) [isto e, inalterado] onde: P() denota o valor de um conjunto de capacidades de thread antes de execve(2) P'() denota o valor de um conjunto de capacidades de thread depois de execve(2) F() denota um conjunto de capacidades de arquivo Observe os seguintes detalhes relacionados as regras de transformacao de capacidades acima: o O conjunto de capacidades de ambiente esta presente somente desde o Linux 4.3. Ao determinar a transformacao do conjunto de ambiente durante execve(2), um arquivo privilegiado e aquele que tem capacidades ou tem o bit set-user-ID ou set-group-ID definido. o 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 execve(2) da mesma maneira mostrada acima para P(bounding). Note: during the capability transitions described above, file capabilities may be ignored (treated as empty) for the same reasons that the set-user-ID and set-group-ID bits are ignored; see execve(2). File capabilities are similarly ignored if the kernel was booted with the no_file_caps option. Nota: de acordo com as regras acima, se um processo com IDs de usuario diferentes de zero executar um execve(2), quaisquer capacidades que estejam presentes em seus conjuntos permitidos e efetivos serao limpas. Para o tratamento de capacidades quando um processo com uma ID de usuario zero executa um execve(2), consulte Capacidades e execucao de programas pelo root abaixo. Verificacao de seguranca para binarios sem suporte a capacidades Um binario sem suporte a capacidades e um aplicativo que foi marcado para ter capacidades de arquivo, mas nao foi convertido para usar a API libcap(3) para manipular suas capacidades. (Em outras palavras, este e um programa tradicional set-user-ID-root que foi alternado para usar recursos de arquivo, mas cujo codigo nao foi modificado para entender os recursos.) Para tais aplicativos, o bit de capacidade efetiva e 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 nao tendo suporte a capacidades para o proposito da verificacao descrita aqui. Ao executar um binario sem suporte a capacidades, o kernel verifica se o processo obteve todos os recursos permitidos que foram especificados no conjunto de arquivos permitidos, apos as transformacoes de recursos descritas acima terem sido executadas. (O motivo tipico pelo qual isso pode nao ocorrer e que o conjunto limitador de recursos mascarou alguns dos recursos no conjunto de arquivos permitidos.) Se o processo nao obteve o conjunto completo de recursos permitidos do arquivo, entao execve(2) falha com o erro EPERM. Isso evita possiveis riscos de seguranca que podem surgir quando um aplicativo sem suporte a capacidades e executado com menos privilegios do que o necessario. Observe que, por definicao, o aplicativo nao poderia reconhecer esse problema, pois nao emprega a API do libcap(3). Capacidades e execucao de programas pelo root Para espelhar a semantica 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 e executado. Apos ter realizado quaisquer alteracoes no ID efetivo do processo que foram acionadas pelo bit de modo set-user-ID do binario -- por exemplo, alternando o ID efetivo do usuario para 0 (root) porque um programa set-user-ID-root foi executado -- o kernel calcula os conjuntos de capacidades de arquivo da seguinte forma: (1) 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 Set-user-ID-root programs that have file capabilities below.) (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). 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 execve(2). Thus, when a process with nonzero UIDs execve(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 execve(2)s a program, the calculation of the process's new permitted capabilities simplifies to: P'(permitted) = P(inheritable) | P(bounding) P'(effective) = P'(permitted) Consequentemente, o processo ganha todas as capacidades em seus conjuntos de capacidades permitidas e efetivas, exceto aquelas mascaradas pelo conjunto limitador de capacidades. (No calculo de P'(permitted), o termo P'(ambient) pode ser simplificado porque e, por definicao, um subconjunto proprio de P(inheritable).) The special treatments of user ID 0 (root) described in this subsection can be disabled using the securebits mechanism described below. Set-user-ID-root programs that have file capabilities There is one exception to the behavior described in Capabilities and execution of programs by root above. If (a) the binary that is being executed has capabilities attached and (b) the real user ID of the process is not 0 (root) and (c) the effective user ID of the process is 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). 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. Conjunto limitador de capacidade O conjunto limitador de capacidade e um mecanismo de seguranca que pode ser usado para limitar as capacidades que podem ser obtidas durante um execve(2). O conjunto limitador e usado das seguintes maneiras: o During an execve(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. o (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 capset(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 execve(2)s a file that has the capability in its inheritable set. 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. Depending on the kernel version, the capability bounding set is either a system-wide attribute, or a per-process attribute. Capability bounding set from Linux 2.6.25 onward From Linux 2.6.25, the capability bounding set is a per-thread attribute. (The system-wide capability bounding set described below no longer exists.) The bounding set is inherited at fork(2) from the thread's parent, and is preserved across an execve(2). A thread may remove capabilities from its capability bounding set using the prctl(2) PR_CAPBSET_DROP operation, provided it has the CAP_SETPCAP 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 prctl(2) PR_CAPBSET_READ operation. 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 CONFIG_SECURITY_FILE_CAPABILITIES 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 init process (the ancestor of all processes) begins with a full bounding set. If file capabilities are not compiled into the kernel, then init begins with a full bounding set minus CAP_SETPCAP, because this capability has a different meaning when there are no file capabilities. 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. Capability bounding set prior to Linux 2.6.25 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 /proc/sys/kernel/cap-bound. (Confusingly, this bit mask parameter is expressed as a signed decimal number in /proc/sys/kernel/cap-bound.) Only the init process may set capabilities in the capability bounding set; other than that, the superuser (more precisely: a process with the CAP_SYS_MODULE capability) may only clear capabilities from this set. On a standard system the capability bounding set always masks out the CAP_SETPCAP capability. To remove this restriction (dangerous!), modify the definition of CAP_INIT_EFF_SET in include/linux/capability.h and rebuild the kernel. The system-wide capability bounding set feature was added to Linux 2.2.11. 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 setuid(2), setresuid(2), or similar): o 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. o If the effective user ID is changed from 0 to nonzero, then all capabilities are cleared from the effective set. o If the effective user ID is changed from nonzero to 0, then the permitted set is copied to the effective set. o If the filesystem user ID is changed from 0 to nonzero (see setfsuid(2)), then the following capabilities are cleared from the effective set: CAP_CHOWN, CAP_DAC_OVERRIDE, CAP_DAC_READ_SEARCH, CAP_FOWNER, CAP_FSETID, CAP_LINUX_IMMUTABLE (since Linux 2.6.30), CAP_MAC_OVERRIDE, and CAP_MKNOD (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. 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 SECBIT_KEEP_CAPS securebits flag described below. Ajustando conjuntos de capacidades programaticamente A thread can retrieve and change its permitted, effective, and inheritable capability sets using the capget(2) and capset(2) system calls. However, the use of cap_get_proc(3) and cap_set_proc(3), both provided in the libcap package, is preferred for this purpose. The following rules govern changes to the thread capability sets: o If the caller does not have the CAP_SETPCAP capability, the new inheritable set must be a subset of the combination of the existing inheritable and permitted sets. o (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. o 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). o The new effective set must be a subset of the new permitted set. The securebits flags: establishing a capabilities-only environment Starting with Linux 2.6.26, and with a kernel in which file capabilities are enabled, Linux implements a set of per-thread securebits flags that can be used to disable special handling of capabilities for UID 0 (root). These flags are as follows: SECBIT_KEEP_CAPS 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 execve(2). Note that even with the SECBIT_KEEP_CAPS 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. The setting of the SECBIT_KEEP_CAPS flag is ignored if the SECBIT_NO_SETUID_FIXUP flag is set. (The latter flag provides a superset of the effect of the former flag.) This flag provides the same functionality as the older prctl(2) PR_SET_KEEPCAPS operation. SECBIT_NO_SETUID_FIXUP 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 Effect of user ID changes on capabilities above. SECBIT_NOROOT 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 execve(2). (See Capabilities and execution of programs by root above.) SECBIT_NO_CAP_AMBIENT_RAISE Setting this flag disallows raising ambient capabilities via the prctl(2) PR_CAP_AMBIENT_RAISE operation. 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: SECBIT_KEEP_CAPS_LOCKED, SECBIT_NO_SETUID_FIXUP_LOCKED, SECBIT_NOROOT_LOCKED, and SECBIT_NO_CAP_AMBIENT_RAISE_LOCKED. The securebits flags can be modified and retrieved using the prctl(2) PR_SET_SECUREBITS and PR_GET_SECUREBITS operations. The CAP_SETPCAP capability is required to modify the flags. Note that the SECBIT_* constants are available only after including the header file. The securebits flags are inherited by child processes. During an execve(2), all of the flags are preserved, except SECBIT_KEEP_CAPS which is always cleared. 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: 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 */ Per-user-namespace "set-user-ID-root" 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. The rules about the transformation of the process's capabilities during the execve(2) are exactly as described in Transformation of capabilities during execve() and Capabilities and execution of programs by root above, with the difference that, in the latter subsection, "root" is the UID of the creator of the user namespace. Namespaced file capabilities 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 Transformation of capabilities during execve() above. 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 CAP_SETFCAP 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. Linux 4.14 added so-called namespaced file capabilities to support such use cases. Namespaced file capabilities are recorded as version 3 (i.e., VFS_CAP_REVISION_3) security.capability extended attributes. Such an attribute is automatically created in the circumstances described in File capability extended attribute versioning above. When a version 3 security.capability extended attribute is created, the kernel records not just the capability masks in the extended attribute, but also the namespace root user ID. As with a binary that has VFS_CAP_REVISION_2 file capabilities, a binary with VFS_CAP_REVISION_3 file capabilities confers capabilities to a process during execve(). However, capabilities are conferred only if the binary is executed by a process that resides in a user namespace whose UID 0 maps to the root user ID that is saved in the extended attribute, or when executed by a process that resides in a descendant of such a namespace. Interaction with user namespaces For further information on the interaction of capabilities and user namespaces, see user_namespaces(7). PADROES No standards govern capabilities, but the Linux capability implementation is based on the withdrawn POSIX.1e draft standard . NOTAS When attempting to strace(1) binaries that have capabilities (or set-user-ID-root binaries), you may find the -u option useful. Something like: $ sudo strace -o trace.log -u ceci ./myprivprog From Linux 2.5.27 to Linux 2.6.26, capabilities were an optional kernel component, and could be enabled/disabled via the CONFIG_SECURITY_CAPABILITIES kernel configuration option. The /proc/pid/task/TID/status file can be used to view the capability sets of a thread. The /proc/pid/status 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 CAP_LAST_CAP) are shown as disabled (0). The libcap 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 capset(2) and capget(2). This package also provides the setcap(8) and getcap(8) programs. It can be found at . 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 CAP_SETPCAP capability can manipulate the capabilities of threads other than itself. However, this is only theoretically possible, since no thread ever has CAP_SETPCAP in either of these cases: o In the pre-2.6.25 implementation the system-wide capability bounding set, /proc/sys/kernel/cap-bound, always masks out the CAP_SETPCAP capability, and this can not be changed without modifying the kernel source and rebuilding the kernel. o If file capabilities are disabled (i.e., the kernel CONFIG_SECURITY_FILE_CAPABILITIES option is disabled), then init starts out with the CAP_SETPCAP capability removed from its per-process bounding set, and that bounding set is inherited by all other processes created on the system. VEJA TAMBEM capsh(1), setpriv(1), prctl(2), setfsuid(2), cap_clear(3), cap_copy_ext(3), cap_from_text(3), cap_get_file(3), cap_get_proc(3), cap_init(3), capgetp(3), capsetp(3), libcap(3), proc(5), credentials(7), pthreads(7), user_namespaces(7), captest(8), filecap(8), getcap(8), getpcaps(8), netcap(8), pscap(8), setcap(8) include/linux/capability.h in the Linux kernel source tree TRADUCAO A traducao para portugues brasileiro desta pagina man foi criada por Rafael Fontenelle Esta traducao e uma documentacao livre; leia a Licenca Publica Geral GNU Versao 3 ou posterior para as condicoes de direitos autorais. Nenhuma responsabilidade e aceita. Se voce encontrar algum erro na traducao desta pagina de manual, envie um e-mail para a lista de discussao de tradutores . Linux man-pages 6.18 8 fevereiro 2026 Capacidades(7)