Estou experimentando recursos, no Debian Gnu / Linux.

Copiei / bin / ping para o meu diretório de trabalho atual. Como esperado, ele não funciona, foi originalmente definido como raiz.

Então, dou ao meu ping os recursos mínimos (não raiz) sudo /sbin/setcap cap_net_raw=ep ./ping, e meu ping funciona como esperado.

Em seguida, sudo /sbin/setcap -r ./pingrevogar essa capacidade. Agora não está funcionando conforme o esperado.

Agora eu tento fazer o ping funcionar usando capsh.

capsh não tem privilégios, então eu preciso executá-lo como root, mas depois largue o root e, portanto, todos os outros privilégios.

Acho que também preciso secure-keep-caps, isso não está documentado capsh, mas está no manual de recursos. Eu recebi os números dos bits /usr/include/linux/securebits.h. Eles parecem corretos, pois a saída de --printmostra que esses bits estão corretos.

Eu tenho mexido por horas, até agora eu tenho isso.

sudo /sbin/capsh --keep=1 --secbits=0x10 --caps="cap_net_raw+epi" == --secbits=0x10 --user=${USER} --print -- -c "./ping localhost"

No entanto ping, com erros ping: icmp open socket: Operation not permitted, é isso que acontece quando ele não tem capacidade. Também os --printshows Current: =p cap_net_raw+i, isso não é suficiente, precisamos e.

sudo /sbin/capsh --caps="cap_net_raw+epi" --print -- -c "./ping localhost"irá definir a capacidade para Current: = cap_net_raw+eipisso está correto, mas nos deixa como root.

Edit-1

Eu já tentei sudo /sbin/capsh --keep=1 --secbits=0x11 --caps=cap_net_raw+epi --print -- -c "touch zz; ./ping -c1 localhost;"

Isso produz:

touch: cannot touch `zz': Permission denied
ping: icmp open socket: Operation not permitted

O primeiro erro é esperado como secure-noroot: yes Mas o segundo não éCurrent: = cap_net_raw+eip

Edit-2

Se eu colocar ==antes do --print, agora mostra Current: = cap_net_raw+i, o que explica o erro anterior, mas não o porquê de perdermos a capacidade ao sair da raiz, embora isso secure-keep-capsdeva corrigir isso.

Edit-3

Pelo que posso ver, estou perdendo Efetivo (e) e Permitido (p), quando exec é chamado. Isso é esperado, mas eu pensei que o secure-keep-caps, deveria impedir que eles se perdessem. Estou esquecendo de algo.

Edit-4

Tenho pesquisado mais e lido o manual novamente. Parece que normalmente ee os precursos são perdidos quando: você muda de usuário root(ou aplica secure-noroot, tornando o usuário root normal), isso pode ser substituído secure-keep-caps; quando você liga exec, até onde eu sei, isso é invariável.

Tanto quanto posso dizer, está funcionando de acordo com o manual. Até onde eu sei, não há como fazer algo útil capsh. Tanto quanto posso dizer, para usar recursos, você precisa: usar recursos de arquivo ou ter um programa que reconhece recursos, que não usa exec. Portanto, nenhum invólucro privilegiado.

Então agora minha pergunta é o que estou perdendo, para que serve capsh.

Edit-5

Adicionei uma resposta aos recursos ambientais. Talvez capshtambém possa ser usado com recursos herdados, mas para serem úteis, eles precisam ser configurados no arquivo executável. Não vejo como o capsh pode fazer algo útil sem os recursos do ambiente ou para permitir recursos herdados.

Versões:

• capshda libcap2-binversão do pacote1:2.22-1.2
• antes de editar-3 Peguei o mais recente capshde git://git.debian.org/collab-maint/libcap2.gite começou a usá-lo.
• uname -a Linux richard-laptop 3.2.0-4-amd64 #1 SMP Debian 3.2.65-1+deb7u2 x86_64 GNU/Linux A área do usuário é 32 bits.

Capacidades são propriedades de processos. Tradicionalmente, existem três conjuntos:

• Recursos permitidos ( p ): recursos que podem ser "ativados" no processo atual.
• Recursos efetivos ( e ): recursos atualmente utilizáveis ​​no processo atual.
• Recursos herdáveis ​​( i ): recursos de arquivo que podem ser herdados.

Os programas executados como raiz sempre têm recursos permitidos e eficazes, portanto, "adicionar" mais recursos não tem efeito perceptível. (O conjunto de recursos herdáveis ​​normalmente está vazio.) Com setcap cap_net_raw+ep pingvocê, esses recursos são ativados por padrão para qualquer usuário que esteja executando este programa.

Infelizmente, esses recursos estão vinculados ao arquivo executado e não são retidos após a execução de um novo processo filho. O Linux 4.3 introduziu recursos Ambient, que permitem que os recursos sejam herdados por processos filhos. (Consulte também Transformação de recursos durante execve () nos recursos (7) .)

Ao jogar com recursos, observe estas armadilhas:

• Ao alterar o utilizador de raiz para não-raiz, o eficaz e capacidades permitidas são apagadas (ver Efeito de alterações de ID utilizador sobre as capacidades em capacidades de (7) ). Você pode usar a --keep=1opção de capshpara evitar limpar os aparelhos.
• O conjunto de recursos ambientais é limpo ao alterar os IDs de usuário ou grupo. Solução: adicione os recursos do ambiente após alterar o ID do usuário, mas antes de executar um processo filho.
• Um recurso pode ser incluído apenas no conjunto de recursos ambientais se já estiver no conjunto de recursos permitidos e herdáveis.

O capshprograma da libcap 2.25 ainda não tem a capacidade de modificar os recursos do ambiente, mas as versões posteriores adicionam novas opções. Observe que a ordem das opções é significativa. Exemplo de uso:

sudo capsh --caps="cap_net_raw+eip cap_setpcap,cap_setuid,cap_setgid+ep" \
    --keep=1 --user=nobody --addamb=cap_net_raw -- \
    -c "./ping -c1 127.0.0.1"

Dica: você pode adicionar a --printopção em qualquer lugar da capshlinha de comando e ver o estado atual dos recursos.

Nota: cap_setpcapé necessário por --addambenquanto cap_setuid,cap_setgidsão necessários para a --useropção.

A resposta de Lekensteyn parece precisa e completa, mas tentarei fornecer outra explicação de um ângulo diferente que tentará enfatizar o problema que as capacidades ambientais configuradas resolvem.

Ao executar sudo capsh --user=<some_user> --Existem duas chamadas de interesse do sistema que fazem com que os recursos sejam recalculados (e potencialmente descartados):

1. setuid: De acordo com man capabilities:

SECBIT_KEEP_CAPS A configuração desse sinalizador permite que um encadeamento que tenha um ou mais 0 UIDs mantenha seus recursos ao alternar todos os seus UIDs para um valor diferente de zero. Se esse sinalizador não estiver definido, esse UIDswitch fará com que o thread perca todos os recursos.

Em outras palavras, em nosso capshcomando acima, precisamos garantir que SECBIT_KEEP_CAPS seja definido durante a setuidchamada do sistema. Caso contrário, todos os recursos serão perdidos. Isto é o que --keep=1faz. Então agora o comando se tornasudo capsh --user=<some_user> --keep=1 --

2. execve: Se usarmos a --keep=1opção, todos os conjuntos de recursos (efetivos, permitidos, herdáveis) serão preservados até a execvechamada do sistema, no entanto, os execverecursos também serão recalculados (para usuários não raiz) e de uma maneira não tão óbvia. Em resumo, antes da adição do conjunto de recursos ambientais , para que um recurso esteja no conjunto "permitido" de um encadeamento após uma execvechamada:

   • O arquivo deve ter esse recurso em seu conjunto "permitido" . Isso pode ser feito com setcap cap_net_raw+p /bin/bash. Isso faz com que todo o exercício seja inútil, pois os conjuntos de recursos do encadeamento (exceto o conjunto delimitador) não têm mais nenhum efeito.
   • O arquivo e o encadeamento devem ter esse recurso em seus conjuntos "herdáveis" . Você pode pensar que setcap cap_net_raw+iisso funcionaria, mas acontece que execveas permissões herdáveis ​​de um encadeamento são descartadas quando chamadas por usuários sem privilégios (às quais somos atualmente agradecidos setuid). Portanto, não há como satisfazer essa condição como um usuário não privilegiado.

Os recursos ambientais introduzidos no Linux 4.3 possibilitam que um encadeamento retenha seus recursos, mesmo após um setuidusuário não privilegiado, seguido por um execve, sem precisar confiar nos recursos do arquivo.

Pode haver um bug / recurso no kernel. Houve alguma discussão:

• https://bugzilla.altlinux.org/show_bug.cgi?id=16694
• http://linux.derkeiler.com/Mailing-Lists/Kernel/2005-03/5224.html

Não faço ideia, se alguma coisa foi feita, para consertar.

Não me interpretem mal - o comportamento atual é seguro. Mas é tão seguro que atrapalha as coisas que parecem funcionar.

Edit: De acordo com http://man7.org/linux/man-pages/man7/capabilities.7.html, existe um novo conjunto de recursos Ambient (desde o Linux 4.3). Parece que isso permitirá o que é necessário.