Como usar bits SUID, SGID e sticky no Linux
Fatmawati Achmad Zaenuri / Shutterstock
SUID, SGID e Sticky Bits são poderosas permissões especiais que você pode definir para executáveis e diretórios no Linux. Compartilharemos os benefícios e as possíveis armadilhas do seu uso.
Eles já estão em uso
Construir a segurança em um sistema operacional multiusuário apresenta vários dilemas. Pegue o (aparentemente) conceito básico de senhas, por exemplo. Todos eles precisam ser armazenados para que, sempre que alguém efetue login, o sistema possa comparar a senha digitada 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: elas 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 pessoas com privilégios de root podem acessar senhas armazenadas, como as pessoas que não têm esse acesso alteram suas senhas?
Elevando seu status
Geralmente, 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 para alterar uma senha, ele é executado com as permissões do root. Isso significa que o comando passwd pode acessar livremente as senhas armazenadas no arquivo / etc / shadow.
O que seria ideal é um esquema no qual qualquer pessoa no sistema possa iniciar o programa passwd, mas faça com que o programa retenha os privilégios elevados da raiz. Isso permitiria que qualquer pessoa alterasse sua própria senha.
O cenário acima é exatamente o que o SUID (Set User ID bit) faz. Ele 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
Há outro dilema, no entanto. A pessoa deve ser impedida de interferir com a senha de qualquer outra pessoa. O Linux incorpora o esquema SUID, que permite executar aplicativos com um conjunto de permissões emprestadas temporariamente, mas isso é apenas metade da história de segurança.
O mecanismo de controle que impede que alguém trabalhe 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 de segurança se eles não forem criados com uma segurança projetada por design. mentalidade. Isso significa que a segurança é a primeira coisa que você considera e depois desenvolve isso. Não escreva seu programa e tente dar uma camada de segurança posteriormente.A maior vantagem do software de código aberto é que você pode consultar o código-fonte ou consultar as resenhas 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. Recursos diferentes são permitidos se alguém for root (ou alguém usando o sudo).
Este é o código que detecta se alguém é root.
A seguir, é apresentado 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 costuma executar para ver quais senhas a pessoa tem permissão para alterar. Portanto, para root, ignora 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 segurança neles e que o código foi revisado várias vezes. Claro, sempre há a ameaça de explorações ainda desconhecidas. No entanto, os patches ou atualizações são rápidos para aparecer para combater quaisquer vulnerabilidades recém-identificadas.
É um software de terceiros, especialmente qualquer software que não seja de código aberto, você precisa ter muito cuidado ao usar o SUID. Não estamos dizendo que não o fazemos, mas, se o fizer, você quer garantir que ele não exponha seu sistema a riscos. Você não deseja elevar os privilégios de um programa que não se autogovernará corretamente e à pessoa que o está executando.
Comandos do Linux que usam SUID
A seguir, alguns comandos do Linux que usam o bit SUID para conceder privilégios elevados ao comando quando executados 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 estão destacados em vermelho, o que indica que o bit SUID está definido.
As permissões em um arquivo ou diretório geralmente são representadas por três grupos de três caracteres: rwx. Eles representam leitura, gravação e execução. Se as cartas estiverem presentes, essa permissão foi concedida. Se um hífen (-) em vez de uma carta estiver presente, essa permissão não foi concedida.
Existem três grupos dessas permissões (da esquerda para a direita): aqueles 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 estiver definido em um arquivo que não possui recursos executáveis, uma letra maiúscula “ S ” denota isso.
Vamos dar uma olhada em um exemplo. O usuário comum dave digita o comando passwd:
senha
O comando passwd solicita dave sua nova senha. Podemos usar o comando ps para ver os detalhes dos processos em execução.
Nós usaremos o ps com grepin em uma janela de terminal diferente e procuraremos o processo de senha. Também usaremos as opções -e (todo processo) e -f (formato completo) com o ps.
Digitamos o seguinte comando:
ps -e -f | grep passwd
Duas linhas são relatadas, a segunda das quais é o processo grep, procurando comandos com a string passwd ” neles. Porém, é a primeira linha que nos interessa, porque é a única para o processo de senhas lançada pela dave.
Podemos ver que o processo passwd é executado da mesma maneira que faria se o root o tivesse lançado.
Configurando o bit SUID
É fácil mudar o bit SUID com o chmod. O modo simbólico u + s define o bit SUID e o modo simbólico u-s 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 possui o bit SUID definido. Quando é executado, ele exibe os IDs de usuário reais e efetivos (UID).
O UID real pertence à pessoa que iniciou o programa. O ID efetivo é a conta em que o programa está se comportando como se tivesse sido lançado por.
Digitamos o seguinte:
ls -lh htg
./ htg
Quando executamos a cópia local do programa, vemos que os IDs reais e efetivos estão definidos para serem exibidos. Então, ele está se comportando 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
Então, o programa é copiado e o bit SUID é definido. Executaremos novamente, mas desta vez executaremos a cópia na pasta / usr / local / bin:
htg
Embora a dave tenha iniciado o programa, o ID efetivo é definido para o usuário root. Portanto, se mary lança o programa, acontece o mesmo, como mostrado abaixo:
htg
O ID real é mary, e o ID efetivo é raiz. O programa é executado com as permissões do usuário root.
RELACIONADO: Como usar o comando chmod no Linux
O bit SGID
O bit Set ID do grupo (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 mostrar também 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 u-s e g + s com chown para remover o bit SUID e definir o SGID.
Para isso, digite o seguinte:
raiz do chown do sudo: 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 indicado pelo “ s ” nas permissões de grupo. Além disso, observe que o grupo está definido como mary 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 (groups) para imprimir todos os IDs de grupo. Em seguida, executaremos o programa htg como dave.
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 pelo dave, ele está sendo executado com as permissões dos membros do grupo mary . É o mesmo que 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 depois mude seu grupo para "nerd". Vamos definir o bit SGID no diretório.
Quando usamos ls para verificar as configurações do diretório, também usaremos a opção -d (diretório) para vermos os detalhes do diretório, não seu conteúdo.
Digitamos os seguintes comandos:
sudo mkdir work
sudo chown dave: trabalho geek
trabalho do sudo chmod g + s
ls -lh -d trabalho
O bit SGID e o "geek" ” grupo está definido. Isso afetará todos os itens criados no diretório de trabalho.
Digitamos o seguinte para entrar no diretório de trabalho, criar um diretório chamado “ demo, ” e verifique suas propriedades:
trabalho em CD
demo do mkdir
ls -lh -d demo
O bit SGID e o "geek" ” grupo é aplicado automaticamente à & demo; “ demo ” diretório.
Digitamos o seguinte para criar um arquivo com o comando touch e verifique suas propriedades:
toque em útil. sh
ls -lh useful. sh
O grupo do novo arquivo é automaticamente definido como "geek". ”
RELACIONADO: Como usar o comando chown no Linux
O bit adesivo
O bit pegajoso recebe o nome de seu objetivo histórico. Quando definido em um executável, ele sinaliza para o sistema operacional que as partes de texto do executável devem ser mantidas em troca, tornando sua reutilização mais rápida. No Linux, o bit pegajoso afeta apenas um diretório que o define em um arquivo não faria sentido.
Quando você define o bit em um diretório, as pessoas podem excluir apenas os arquivos que pertencem a eles dentro desse diretório. Eles não podem excluir arquivos que pertencem a outra pessoa, independentemente da combinação de permissões de arquivo definida nos arquivos.
Isso permite que você crie um diretório que todos os usuários e os processos iniciados possam usar como armazenamento compartilhado de arquivos. Os arquivos estão protegidos porque, novamente, ninguém pode excluir os arquivos de mais ninguém.
Vamos criar um diretório chamado 'shared'. '” Usaremos o modo simbólico o + t com chmod para definir o bit pegajoso nesse diretório. Vamos examinar as permissões nesse diretório, bem como os diretórios / tmp e / var / tmp.
Digitamos os seguintes comandos:
mkdir compartilhou
sudo chmod o + t compartilhado
ls -lh -d compartilhou
ls -lh -d / tmp
ls -lh -d / var / tmp
Se o bit adesivo estiver definido, o bit executável do “ outro ” O conjunto de permissões de arquivo está 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 possuem todas as permissões de arquivo definidas para o proprietário, grupo e outros (é por isso que são destacados em verde). Eles são usados como locais compartilhados para arquivos temporários.
Com essas permissões, qualquer um deve, teoricamente, ser capaz de fazer qualquer coisa. No entanto, o bit pegajoso os substitui e ninguém pode excluir um arquivo que não pertence a ele.
Lembretes
A seguir, é apresentada uma lista rápida do que abordamos acima para referência futura:
- O SUID funciona apenas em arquivos.
- Você pode aplicar o SGID a diretórios e arquivos.
- Você pode aplicar o bit persistente apenas a diretórios. < li> Se o “ s “, “ g “, ou “ t ” os indicadores aparecem em maiúsculas, o bit executável (x) não foi definido.
Via: How to Geek
Veja Também:
Nenhum comentário