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 potenciais armadilhas – de usá-los.
Índice
Eles já estão em uso
Construir segurança em um sistema operacional multiusuário apresenta vários dilemas. Veja 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 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: são criptografadas e apenas alguém com rootprivilégios pode acessar o arquivo que contém as senhas. Isso pode parecer bom, mas apresenta um dilema: se apenas pessoas com root privilégios 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 rootexecuta o passwdcomando para alterar uma senha , ele executa com rootas permissões de. Isso significa que o passwdcomando pode acessar livremente as senhas armazenadas no /etc/shadowarquivo.
O ideal seria um esquema em que qualquer pessoa no sistema pudesse iniciar o passwdprograma, mas fazer com que o passwdprograma retivesse rootos privilégios elevados. Isso capacitaria qualquer pessoa a alterar sua própria senha.
O cenário acima é exatamente o que o bit Definir ID do usuário ( SUID) 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
Porém, há outro dilema. A pessoa deve ser impedida de interferir na senha de outra pessoa. O Linux incorpora o SUID esquema que permite executar aplicativos com um conjunto de permissões emprestadas temporariamente – mas isso é apenas metade da história da segurança.
O mecanismo de controle que impede alguém de trabalhar com a senha de outra pessoa está contido no passwdprograma, 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 que você considera e, em seguida, você se baseia nela. Não escreva seu programa e tente dar a ele uma camada de segurança depois.
A maior vantagem do software de código-fonte aberto é que você mesmo pode examinar o código-fonte ou consultar análises de pares confiáveis dele. No código-fonte do passwdprograma, existem verificações, para que você possa ver se a pessoa que está executando o programa está root. Diferentes recursos são permitidos se alguém estiver root(ou alguém usando sudo).
Este é o código que detecta se alguém está root.
A seguir está um exemplo em que isso é levado em consideração. Como 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. Portanto, rootele 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 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 – e você precisa ser extremamente cuidadoso ao usar o SUID. Não estamos dizendo para não fazer isso, mas, se o fizer, você quer 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 estã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. Se um hífen ( -) em vez de uma letra estiver presente, entretanto, 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 SUIDbit é definido em um arquivo, um “s” representa a permissão de execução do proprietário.
Se o SUIDbit for definido em um arquivo que não possui recursos executáveis, um “S” maiúsculo indica isso.
Vamos dar uma olhada em um exemplo. O usuário comum dave digita o passwdcomando:
senha
O passwdcomando solicita davesua nova senha. Podemos usar o pscomando para ver os detalhes dos processos em execução .
Usaremos ps com grep em uma janela de terminal diferente e olhar para o passwdprocesso. 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 grepprocesso que procura comandos com a string “passwd” neles. É a primeira linha que nos interessa, porém, porque é essa linha do passwdprocesso davelançado.
Podemos ver que o passwdprocesso funciona da mesma forma que se o root tivesse iniciado.
Configurando o bit SUID
É fácil mudar de SUIDbit chmod. O u+smodo simbólico define o SUIDbit e o u-smodo simbólico limpa o SUIDbit.
Para ilustrar alguns dos conceitos do bit SUID, criamos um pequeno programa chamado htg. Está no diretório raiz do daveusuário e não tem o SUIDbit definido. Quando é executado, exibe os IDs de usuário ( UID ) reais e efetivos .
O UID real 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 definidos como dave. Portanto, está se comportando exatamente como um programa normal deveria.
Vamos copiá-lo para o /usr/local/bindiretório para que outros possam usá-lo.
Digitamos o seguinte, usando chmodpara definir o SUIDbit 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 /usr/local/binpasta:
htg
Mesmo depois de davelançado o programa, o ID efetivo é definido para o rootusuário. Assim, ao mary iniciar o programa, acontece a mesma coisa, conforme mostrado a seguir:
htg
O ID real é marye o ID efetivo é root. O programa é executado com as permissões do usuário root.
O bit SGID
O SGIDbit Set Group ID ( ) é muito semelhante ao SUIDbit. Quando o SGIDbit é 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 htgprograma para mostrar o grupo eficaz também. Vamos mudar o grupo do htgprograma para o marygrupo padrão do usuário mary,. Também usaremos os modos simbólicos u-se g+scom chown para remover o SUIDbit e definir o SGID.
Para fazer isso, digitamos o seguinte:
sudo chown root: mary / usr / local / bin / htg
sudo chmod us, g + s / usr / local / bin / htg
ls -lh / usr / local / bin / htg
Você pode ver o SGIDbit denotado pelo “s” nas permissões do grupo. Além disso, observe que o grupo está definido como mary e o nome do arquivo agora está destacado em amarelo.
Antes de executarmos o programa, vamos estabelecer a quais grupos davee a que marypertencer. Usaremos o idcomando com a -Gopção (grupos), para imprimir todos os IDs de grupo . Em seguida, executaremos o htgprograma como dave.
Nós digitamos os seguintes comandos:
id -G dave
id -G maria
htg
O ID do grupo padrão para mary é 1001, e o grupo efetivo do htgprograma é 1001. Portanto, embora tenha sido iniciado por dave, está sendo executado com as permissões dos membros do marygrupo. É como se davetivesse entrado no marygrupo.
Vamos aplicar o SGIDbit a um diretório. Primeiro, criaremos um diretório chamado “trabalho” e, em seguida, alteraremos seu grupo para “geek”. Em seguida, definiremos o SGIDbit no diretório.
Quando usamos ls para verificar as configurações do diretório, também usamos a -dopção (diretório) para ver os detalhes do diretório, não seu conteúdo.
Nós digitamos os seguintes comandos:
sudo mkdir trabalho
sudo chown dave: trabalho geek
sudo chmod g + s trabalho
ls -lh -d trabalho
O SGIDbit e o grupo “geek” estão definidos. Isso afetará todos os itens criados no workdiretório.
Digitamos o seguinte para entrar no workdiretório, criamos um diretório chamado “demo” e verificamos suas propriedades:
trabalho de cd
demonstração mkdir
ls -lh -d demo
O SGIDbit e o grupo “geek” são automaticamente aplicados ao diretório “demo”.
Vamos digitar o seguinte para criar um arquivo com o touchcomando e verificar suas propriedades:
toque em útil.sh
ls -lh útil.sh
O grupo do novo arquivo é definido automaticamente como “geek”.
The Sticky Bit
O sticky bit 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 nesse 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 compartilhado. 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 o+tmodo simbólico com chmodpara definir o sticky bit nesse diretório. Em seguida, examinaremos as permissões nesse diretório, bem como os diretórios /tmpe /var/tmp.
Nós digitamos os seguintes comandos:
mkdir compartilhado
sudo chmod o + t compartilhado
ls -lh -d compartilhado
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 /tmpe /var/tmpsã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 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 lhe pertence.
Lembretes
A seguir está uma lista de verificação rápida do que cobrimos acima para referência futura:
SUIDsó funciona em arquivos.- Você pode aplicar
SGIDa 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.
