Como eu uso o capsh: Estou tentando executar um ping sem privilégios, com recursos mínimos

9

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
  • antes da edição 3 peguei a última 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.
por ctrl-alt-delor 16.04.2015 / 01:32

3 respostas

2

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.

    
por 16.04.2015 / 13:49
7

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

  • Capacidades permitidas ( p ): recursos que podem ser "ativados" no processo atual.
  • Capacidades efetivas ( e ): recursos atualmente utilizáveis no processo atual.
  • Capacidades herdáveis ( i ): recursos de arquivos que podem ser herdados.

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.

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

Ao jogar com recursos, observe estas armadilhas:

  • Ao alterar o usuário do root para o non-root, os recursos efetivos e permitidos são limpos (consulte Efeito das alterações do ID do usuário nos recursos em capabilities (7) ). Você pode usar a opção --keep=1 de capsh para evitar limpar os conjuntos.
  • O conjunto de recursos do ambiente é limpo ao alterar os IDs do usuário ou do grupo. Solução: adicione os recursos do ambiente após alterar o ID do usuário, mas antes executando um processo filho.
  • Um recurso só pode ser adicionado aos recursos de ambiente definidos se ele já estiver no conjunto de recursos permitidos e herdáveis.

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 .

    
por 16.08.2016 / 16:27
3

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):

  1. 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 --

  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 :

    • O arquivo deve ter esse recurso em seu conjunto "permitido" . Isso pode ser feito com 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.
    • O arquivo e o encadeamento devem ter esse recurso em seus conjuntos "herdáveis" . Você pode pensar que 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.

    
por 07.09.2017 / 09:39