Como usar SUID, SGID e Sticky Bits no Linux

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.

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:

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