Tíquetes de sudo e subseqüente processo de irmãos não-sudo

Question

Imagine que localmente no meu sistema sudo está configurado com um tempo limite, para que, uma vez autenticado depois de executar sudo uma vez em algum terminal, eu não precise autenticar novamente por mais 10 minutos.

Isso efetivamente fornece processos em execução como filhos do processo que invocou sudo , mas não com sudo (por isso, como irmãos, não filhos ) processo que foi executado com sudo ) a capacidade de escalar seus privilégios para o root?

Como exemplo concreto, imagine que corro no terminal:

sudo echo "hi"
other_process

O processo echo é executado com sudo , mas other_process não é. Pode other_process usar o tíquete sudo de expiração de 10 minutos associado à chamada anterior sudo , por exemplo, lançando um subprocesso via sudo ?

Eu acho que se a resposta for sim, significa que você precisa ter muito cuidado com qualquer processo executado dentro do período de tempo limite de sudo . Pode-se imaginar que a execução de um processo não confiável, como other_process , o manteria dentro da caixa de proteção do usuário atual, mas, se ele puder usar o tiquetaque sudo existente, poderá escalar para raiz.

A resposta muda se a invocação sudo não vier diretamente no terminal, mas em um script iniciado a partir do terminal?

Por exemplo, corro:

script.sh
other_process2

Se dentro de script.sh , houver uma linha como sudo echo "inside script" , outros processos lançados posteriormente pelo script poderão usar o tíquete sudo para escalar seus privilégios para o root? Que tal depois que o script terminar: outros processos no terminal que executaram script.sh ainda poderão usar o sudo ticket ¹ ?

¹ Estes não são mais como irmãos, mas de alguma forma processos 'tia' ou 'tio' (irmãos dos pais).

    

Answer 1

Sim, o ticket sudo é bom para qualquer processo em execução nesse terminal (pelo menos executando como seu usuário). Isso é fácil de testar. Apenas faça um test.sh (ou qualquer outro) com:

#!/bin/sh

sudo apt-get check

Então:

$ sudo apt-get check
[sudo] password for anthony: 
Reading package lists... Done
Building dependency tree       
Reading state information... Done

$ ./test.sh 
Reading package lists... Done
Building dependency tree       
Reading state information... Done

Geralmente, não é aconselhável executar programas não confiáveis, especialmente como usuário. E você certamente não deve fazê-lo em um terminal para o qual você tenha um ingresso para o sudo. Se você precisa executar programas não confiáveis, deve configurar barreiras de segurança (no mínimo, um usuário diferente, mas ainda melhor seria uma VM ou pelo menos um contêiner - configurar uma caixa de proteção segura para executar programas não confiáveis é não-trivial). ).

    

Answer 2

Sim. Como a sudo de autorização está vinculada a uma combinação de seu nome de usuário e tty e um timestamp, qualquer comando executado a partir desse shell poderia transmitir a capacidade de elevar privilégios via sudo sem digitar sua senha (supondo que você não tenha timestamp_timeout=0 no seu arquivo /etc/sudoers ).

Contanto que esses scripts sejam executados em qualquer tempo que você tenha definido (padrão = 15 minutos).

arquivo test.sh:

#!/bin/bash

echo "test: \$SHLVL is: $SHLVL"
echo "test: I am $(id) on $(tty)"
echo "test: with sudo I am $(sudo id) on $(tty)"
/bin/bash -l ./sudotest.sh

arquivo sudotest.sh:

#!/bin/bash

echo "sudotest: \$SHLVL is: $SHLVL"
echo "sudotest: I am $(id) on $(tty)"
echo "sudotest: with sudo I am $(sudo id) on $(tty)"

resulta em:

test: $SHLVL is: 2
test: I am uid=1000(tim) gid=1000(tim) groups=1000(tim) on /dev/pts/7
[sudo] password for tim:
test: with sudo I am uid=0(root) gid=0(root) groups=0(root) on /dev/pts/7
sudotest: $SHLVL is: 3
sudotest: I am uid=1000(tim) gid=1000(tim) groups=1000(tim) on /dev/pts/7
sudotest: with sudo I am uid=0(root) gid=0(root) groups=0(root) on /dev/pts/7

Nesse caso, a primeira chamada para sudo estava em test.sh , mas sudotest.sh foi não chamado com sudo, mas como meu nome de usuário e tty ainda são os mesmos, sudo reconheceu que processo como sendo elegível para privilégios elevados e não solicitou uma senha durante a execução de sudotest.sh .

E se eu executar novamente depois de alguns minutos, mas antes do tempo limite:

test: $SHLVL is: 2
test: I am uid=1000(tim) gid=1000(tim) groups=1000(tim) on /dev/pts/7
test: with sudo I am uid=0(root) gid=0(root) groups=0(root) on /dev/pts/7
sudotest: $SHLVL is: 3
sudotest: I am uid=1000(tim) gid=1000(tim) groups=1000(tim) on /dev/pts/7
sudotest: with sudo I am uid=0(root) gid=0(root) groups=0(root) on /dev/pts/7

Eu não sou solicitado. E eu não faria isso até o limite de tempo timestamp_timeout passar.

Você pode ver que o tty permanece o mesmo durante as execuções, e que SHLVL está incrementando, porque cada processo de shell executado pelo script é um nível mais profundo do shell de chamada. Meu shell interativo, SHLVL = 1 , chama test.sh , que recebe SHLVL = 2 , que chama sudotest.sh , que recebe SHLVL = 3 .

Uma possível ressalva para isso é se você tiver uma versão mais antiga do sudo, em que a opção tty_tickets não está definida, o que remove a granularidade username + tty para sessões sudo e limita a granularidade somente ao nome de usuário e registro de data e hora. p>

Outras opções de sudoers também podem ter impacto, como requiretty .

Desde que as chamadas subseqüentes a sudo dos scripts chamados pelo shell original sejam emitidas dentro do limite de tempo na retenção de credenciais do sudo, elas poderão se elevar como o mesmo usuário. Quando o limite de tempo estiver esgotado, eles precisarão ter uma maneira de inserir novamente a senha se você quiser que eles continuem a elevar os privilégios. (ou você pode alterar o tempo limite ou desativar os requisitos de senha para um usuário ou um comando ... mas esses estão fora do escopo para essa resposta).

    

Answer 3

A resposta é não. Experimente sudo id seguido de id para verificar.