SUID, SGID e Sticky Bits são permissões especiais poderosas que você pode definir para executáveis e diretórios no Linux. Compartilharemos os benefícios – e as armadilhas potenciais – de usá-los.
últimas postagens
Eles já estão em uso
Construir segurança em um sistema operacional multiusuário apresenta vários dilemas. Considere o (aparentemente) conceito básico de senhas, por exemplo. Todos eles devem ser armazenados para que cada vez que alguém efetue login, o sistema possa comparar a senha que ele digita com a cópia armazenada. Obviamente, como as senhas são as chaves do reino, elas devem ser protegidas.
No Linux, as senhas armazenadas são protegidas de duas maneiras: são criptografadas e apenas alguém com privilégios de root pode acessar o arquivo que contém as senhas. Isso pode parecer bom, mas apresenta um dilema: se apenas as pessoas com privilégios de root podem acessar as senhas armazenadas, como aqueles que não têm esse acesso mudam suas senhas?
Elevando Seu Status
Normalmente, os comandos e programas do Linux são executados com o mesmo conjunto de permissões que a pessoa que inicia o programa. Quando o root executa o comando passwd mudar uma senha, ele roda com as permissões de root. Isso significa que o comando passwd pode acessar livremente as senhas armazenadas no arquivo / etc / shadow.
O ideal seria um esquema em que qualquer pessoa no sistema pudesse iniciar o programa passwd, mas fazer com que o programa passwd mantivesse os privilégios elevados de root. Isso capacitaria qualquer pessoa a alterar sua própria senha.
O cenário acima é precisamente o que o bit Set User ID (SUID) faz. Isto executa programas e comandos com as permissões do proprietário do arquivo, em vez das permissões da pessoa que inicia o programa.
Você está elevando o status do programa
Porém, há outro dilema. A pessoa deve ser impedida de interferir na senha de outra pessoa. O Linux incorpora o esquema SUID, que permite executar aplicativos com um conjunto de permissões temporariamente emprestadas – mas isso é apenas metade da história de segurança.
O mecanismo de controle que impede alguém de trabalhar com a senha de outra pessoa está contido no programa passwd, não no sistema operacional e no esquema SUID.
Os programas executados com privilégios elevados podem representar riscos à segurança se não forem criados com uma mentalidade de “segurança desde o projeto”. Isso significa que a segurança é a primeira coisa a ser considerada e, em seguida, você desenvolve a partir dela. Não escreva seu programa e tente dar a ele uma camada de segurança depois.
A maior vantagem do software de código aberto é você mesmo pode olhar o código-fonte ou consulte as análises por pares confiáveis dele. No código-fonte do programa passwd, há verificações para que você possa ver se a pessoa que está executando o programa é root. Diferentes recursos são permitidos se alguém for root (ou alguém usando sudo).
Isto é o código que detecta se alguém é root.
A seguir está um exemplo em que isso é levado em consideração. Como o root pode alterar qualquer senha, o programa não precisa se preocupar com as verificações que geralmente realiza para ver quais senhas a pessoa tem permissão para alterar. Então, para root, pula essas verificações e sai da função de verificação.
Com os principais comandos e utilitários do Linux, você pode ter certeza de que eles possuem a segurança embutida e que o código foi revisado várias vezes. Claro, sempre há a ameaça de exploits ainda desconhecidos. No entanto, os patches ou atualizações aparecem rapidamente para conter qualquer vulnerabilidade recém-identificada.
É um software de terceiros – especialmente qualquer um que não seja de código aberto – você precisa ser extremamente cuidadoso ao usar SUID com. Não estamos dizendo para não fazer isso, mas, se o fizer, você deseja ter certeza de que não exporá seu sistema a riscos. Você não quer elevar os privilégios de um programa que não irá autogovernar corretamente a si mesmo e à pessoa que o executa.
Comandos Linux que usam SUID
A seguir estão alguns dos comandos do Linux que usam o bit SUID para dar ao comando privilégios elevados quando executado por um usuário comum:
ls -l /bin/su
ls -l /bin/ping
ls -l /bin/mount
ls -l /bin/umount
ls -l /usr/bin/passwd
Observe que os nomes dos arquivos são destacados em vermelho, o que indica que o bit SUID está definido.
As permissões em um arquivo ou diretório são geralmente representadas por três grupos de três caracteres: rwx. Estes significam ler, escrever e executar. Se as cartas estiverem presentes, essa permissão foi concedida. Porém, se um hífen (-) em vez de uma letra estiver presente, essa permissão não foi concedida.
Existem três grupos dessas permissões (da esquerda para a direita): aquelas para o proprietário do arquivo, para os membros do grupo do arquivo e para outros. Quando o bit SUID é definido em um arquivo, um “s” representa a permissão de execução do proprietário.
Se o bit SUID for definido em um arquivo que não tem recursos executáveis, um “S” maiúsculo denota isso.
Vamos dar uma olhada em um exemplo. O usuário regular dave digita o comando passwd:
passwd
O comando passwd solicita a Dave sua nova senha. Podemos usar o comando ps para ver os detalhes dos processos em execução.
Usaremos ps com grep em uma janela de terminal diferente e procure o processo passwd. Também usaremos as opções -e (todos os processos) e -f (formato completo) com ps.
Nós digitamos o seguinte comando:
ps -e -f | grep passwd
Duas linhas são relatadas, a segunda das quais é o processo grep procurando por comandos com a string “passwd” neles. No entanto, é a primeira linha que nos interessa, porque é aquela para o processo passwd que dave lançou.
Podemos ver que o processo passwd é executado da mesma forma que se o root o tivesse iniciado.
Configurando o bit SUID
É fácil mudar o bit SUID com chmod. O modo simbólico u + s define o bit SUID e o modo simbólico us limpa o bit SUID.
Para ilustrar alguns dos conceitos do bit SUID, criamos um pequeno programa chamado htg. Ele está no diretório raiz do usuário dave e não tem o bit SUID definido. Quando é executado, ele exibe os IDs de usuário reais e eficazes (UID)
O Real UID pertence à pessoa que lançou o programa. O ID efetivo é a conta pela qual o programa está se comportando como se tivesse sido iniciado.
Nós digitamos o seguinte:
ls -lh htg
./htg
Quando executamos a cópia local do programa, vemos que os IDs reais e efetivos estão configurados para dave. Portanto, ele está se comportando exatamente como um programa normal deveria.
Vamos copiá-lo para o diretório / usr / local / bin para que outros possam usá-lo.
Digitamos o seguinte, usando chmod para definir o bit SUID e, em seguida, verificamos se ele foi definido:
sudo cp htg /usr/local/bin
sudo chmod u+s /usr/local/bin/htg
ls -hl /usr/local/bin/htg
Portanto, o programa é copiado e o bit SUID é definido. Vamos executá-lo novamente, mas desta vez vamos executar a cópia na pasta / usr / local / bin:
htg
Mesmo que dave tenha lançado o programa, o ID efetivo é definido para o usuário root. Então, se mary iniciar o programa, acontece a mesma coisa, conforme mostrado a seguir:
htg
O ID real é mary e o ID efetivo é root. O programa é executado com as permissões do usuário root.
O bit SGID
O bit Set Group ID (SGID) é muito semelhante ao bit SUID. Quando o bit SGID é definido em um arquivo executável, o grupo efetivo é definido como o grupo do arquivo. O processo é executado com as permissões dos membros do grupo do arquivo, em vez das permissões da pessoa que o iniciou.
Ajustamos nosso programa htg para que ele também mostre o grupo eficaz. Vamos mudar o grupo do programa htg para ser o grupo padrão do usuário mary, mary. Também usaremos os modos simbólicos us e g + s com chown para remover o bit SUID e definir o SGID.
Para fazer isso, digitamos o seguinte:
sudo chown root:mary /usr/local/bin/htg
sudo chmod u-s,g+s /usr/local/bin/htg
ls -lh /usr/local/bin/htg
Você pode ver o bit SGID denotado por “s” nas permissões do grupo. Além disso, observe que o grupo está definido como maria e o nome do arquivo agora está destacado em amarelo.
Antes de executar o programa, vamos estabelecer a quais grupos dave e mary pertencem. Usaremos o comando id com a opção -G (grupos), para imprimir todos os IDs de grupo. Em seguida, executaremos o programa htg como dave.
Nós digitamos os seguintes comandos:
id -G dave
id -G mary
htg
O ID do grupo padrão para mary é 1001, e o grupo efetivo do programa htg é 1001. Portanto, embora tenha sido iniciado por dave, está sendo executado com as permissões dos membros do grupo mary. É como se dave tivesse se juntado ao grupo mary.
Vamos aplicar o bit SGID a um diretório. Primeiro, criaremos um diretório chamado “trabalho” e, em seguida, alteraremos seu grupo para “geek”. Em seguida, definiremos o bit SGID no diretório.
Quando usamos ls para verificar as configurações do diretório, também usamos a opção -d (diretório) para ver os detalhes do diretório, não seu conteúdo.
Nós digitamos os seguintes comandos:
sudo mkdir work
sudo chown dave:geek work
sudo chmod g+s work
ls -lh -d work
O bit SGID e o grupo “geek” estão definidos. Isso afetará todos os itens criados no diretório de trabalho.
Digamos o seguinte para entrar no diretório de trabalho, criamos um diretório chamado “demo” e verificamos suas propriedades:
cd work
mkdir demo
ls -lh -d demo
O bit SGID e o grupo “geek” são automaticamente aplicados ao diretório “demo”.
Vamos digitar o seguinte para criar um arquivo com o toque comando e verifique suas propriedades:
touch useful.sh
ls -lh useful.sh
O grupo do novo arquivo é definido automaticamente como “geek”.
A parte pegajosa
A parte pegajosa recebe o nome de seu propósito histórico. Quando definido em um executável, ele sinalizava para o sistema operacional que as partes de texto do executável deveriam ser mantidas em swap, tornando sua reutilização mais rápida. No Linux, o sticky bit afeta apenas um diretório – defini-lo em um arquivo não faria sentido.
Quando você define o sticky bit em um diretório, as pessoas só podem excluir arquivos que pertencem a elas dentro desse diretório. Eles não podem excluir arquivos que pertencem a outra pessoa, não importa a combinação de permissões de arquivo definida nos arquivos.
Isso permite que você crie um diretório que todos – e os processos que eles iniciam – podem usar como armazenamento de arquivos compartilhados. Os arquivos estão protegidos porque, novamente, ninguém pode excluir os arquivos de outra pessoa.
Vamos criar um diretório chamado “compartilhado”. Usaremos o modo simbólico o + t com chmod para definir o sticky bit nesse diretório. Em seguida, examinaremos as permissões nesse diretório, bem como os diretórios / tmp e / var / tmp.
Nós digitamos os seguintes comandos:
mkdir shared
sudo chmod o+t shared
ls -lh -d shared
ls -lh -d /tmp
ls -lh -d /var/tmp
Se o bit sticky estiver definido, o bit executável do “outro” conjunto de permissões de arquivo será definido como “t”. O nome do arquivo também é destacado em azul.
As pastas / tmp e / var / tmp são dois exemplos de diretórios que têm todas as permissões de arquivo definidas para o proprietário, grupo e outros (é por isso que estão destacados em verde). Eles são usados como locais compartilhados para arquivos temporários.
Com essas permissões, qualquer um deveria, teoricamente, ser capaz de fazer qualquer coisa. No entanto, o sticky bit os substitui e ninguém pode excluir um arquivo que não pertence a ele.
Lembretes
A seguir está uma lista de verificação rápida do que cobrimos acima para referência futura:
SUID só funciona em arquivos.
Você pode aplicar SGID a diretórios e arquivos.
Você só pode aplicar o sticky bit a diretórios.
Se os indicadores “s“, “g“ ou “t” aparecerem em maiúsculas, o bit executável (x) não foi definido.