Estou experimentando recursos no Debian GNU / Linux.
Eu copiei / bin / ping para o meu diretório de trabalho atual. Como esperado, não funciona, foi originalmente root setuid.
Eu, então, dou meu ping com os recursos mínimos (não root) fazendo sudo /sbin/setcap cap_net_raw=ep ./ping , e meu ping funciona, como esperado.
Em seguida, sudo /sbin/setcap -r ./ping para revogar essa capacidade. Agora não está funcionando como esperado.
Agora tento fazer o ping funcionar usando capsh .
capsh não tem privilégios, portanto, preciso executá-lo como root, mas, em seguida, descartar raiz e, assim, todos os outros privilégios.
Acho que também preciso de secure-keep-caps , isso não está documentado em capsh , mas está no manual de recursos. Eu tenho os números de bits de /usr/include/linux/securebits.h . Eles parecem corretos, pois a saída de --print mostra 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 erros com ping: icmp open socket: Operation not permitted , é o que acontece quando não tem capacidade. Além disso, o --print mostra Current: =p cap_net_raw+i , isso não é suficiente, precisamos de e .
sudo /sbin/capsh --caps="cap_net_raw+epi" --print -- -c "./ping localhost" definirá a capacidade para Current: = cap_net_raw+eip , mas nos deixa como root .
Editar-1
Já experimentei 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
Editar-2
Se eu colocar == antes do --print , ele mostrará Current: = cap_net_raw+i , então isso explica o erro anterior, mas não porque estamos perdendo capacidade ao sair do root, eu acho que secure-keep-caps deve corrigir isso.
Editar-3
Pelo que vejo, estou perdendo Effective (e) e Permitted (p), quando exec é chamado. Isso é esperado, mas achei que secure-keep-caps deveria impedi-los de serem perdidos. Estou faltando alguma coisa?
Editar-4
Estou pesquisando mais e lendo o manual novamente. Parece que normalmente os recursos e e p são perdidos quando: você alterna do usuário root (ou aplica secure-noroot , tornando root um usuário normal), isso pode ser substituído por secure-keep-caps ; quando você chama exec , tanto quanto eu posso dizer isso é invariante.
Tanto quanto eu posso dizer, está trabalhando de acordo com o manual. Tanto quanto eu posso dizer, não há como fazer algo útil com capsh . Tanto quanto eu posso dizer, para usar os recursos que você precisa: usar recursos de arquivo ou ter um programa ciente de recursos, que não usa exec . Portanto, nenhum wrapper privilegiado.
Então, agora, minha pergunta é o que estou perdendo, o que é capsh .
Versões:
capsh do pacote libcap2-bin versão 1:2.22-1.2
capsh de git://git.debian.org/collab-maint/libcap2.git e comecei a usá-la. uname -a Linux richard-laptop 3.2.0-4-amd64 #1 SMP Debian 3.2.65-1+deb7u2 x86_64 GNU/Linux
O usuário-terra é 32bit. Pode haver um bug / recurso no kernel. Houve alguma discussão:
Eu não tenho ideia, se alguma coisa foi feita, para corrigi-lo.
Don't get me wrong - the current behaviour is secure. But it's so secure that it gets in the way of things which should appear to work.
Edit: De acordo com o link , há um novo conjunto de recursos Ambient (desde o Linux 4.3). Parece que isso permitirá o que é necessário.
Capacidades são propriedades de processos. Tradicionalmente, existem três conjuntos:
Os programas executados como root sempre têm recursos permitidos e efetivos completos, portanto, "adicionar" mais recursos não tem nenhum efeito perceptível. (O conjunto de recursos hereditários está normalmente vazio.) Com setcap cap_net_raw+ep ping , você ativa esses recursos por padrão para qualquer usuário que esteja executando este programa.
Ao jogar com recursos, observe estas armadilhas:
--keep=1 de capsh para evitar limpar os conjuntos. O programa capsh da libcap 2.25 não tem a capacidade de modificar capacidades de ambiente ainda, mas o atual git version adiciona novas opções. Observe que a ordem de 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 opção --print em qualquer lugar na linha de comando capsh e ver seu estado atual de recursos.
Observação: cap_setpcap é necessário para --addamb , enquanto cap_setuid,cap_setgid são necessários para a opção --user .
A resposta de Lekensteyn parece precisa e completa, mas tentarei fornecer outra explicação a partir de um ângulo diferente que tentará enfatizar o problema que as capacidades do ambiente configuradas resolvem.
Quando você executa sudo capsh --user=<some_user> -- Há duas chamadas de sistema de interesse que fazem com que os recursos sejam recalculados (e potencialmente descartados):
setuid : de acordo com man capabilities : SECBIT_KEEP_CAPS Setting this flag allows a thread that has one or more 0 UIDs to retain its capabilities when it switches all of its UIDs to a nonzero value. If this flag is not set, then such a UIDswitch causes the thread to lose all capabilities.
Em outras palavras, em nosso comando capsh acima, precisamos garantir que SECBIT_KEEP_CAPS seja definido durante a chamada do sistema setuid . Caso contrário, todos os recursos serão perdidos. Isso é o que o --keep=1 faz. Então agora o comando se torna sudo capsh --user=<some_user> --keep=1 --
execve : Se usarmos a opção --keep=1 , todos os conjuntos de recursos (efetivo, permitido, herdável) serão preservados até a chamada do sistema execve , mas execve causa recursos para ser recalculado (para usuários não-root) também, e de uma maneira não tão óbvia. Em suma, antes da adição do conjunto de recursos do ambiente , para que um recurso esteja no conjunto "permitido" de um encadeamento após uma chamada execve :
setcap cap_net_raw+p /bin/bash . Fazer isso torna todo o exercício inútil, já que os conjuntos de recursos do encadeamento (além do conjunto delimitador) não têm mais nenhum efeito. setcap cap_net_raw+i faria o truque, mas acontece que execve faz com que as permissões inerentes de um thread sejam descartadas quando chamadas por usuários não privilegiados (que atualmente são graças a setuid ). Portanto, não há como satisfazer essa condição como um usuário sem privilégios. Os recursos de ambiente introduzidos no Linux 4.3 possibilitam que um thread retenha seus recursos mesmo depois de um setuid para um usuário não privilegiado, seguido por um execve , sem depender dos recursos de arquivo.
Tags capabilities