Como usar SUID, SGID e Sticky Bits no Linux

• Dave McKay

  @TheGurkha

• 26 de fevereiro de 2020, 8:00am EDT

SUID, SGID, e Sticky Bits são permissões especiais poderosas que você pode definir para executáveis e diretórios no Linux. Vamos compartilhar os benefícios – e potenciais armadilhas – de usá-los.

Já estão em uso

Construindo a segurança em um sistema operacional multiusuário apresenta vários quandaries. Pegue o conceito (aparentemente) básico de senhas, por exemplo. Todas elas têm que ser armazenadas para que cada vez que alguém faz 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: elas são criptografadas, e somente alguém com root privilégios pode acessar o arquivo que contém as senhas. Isso pode soar bem, mas apresenta um quandary: Se apenas pessoas com root privilégios podem acessar senhas armazenadas, como aqueles que não têm esse acesso podem alterar suas senhas?

Elevating Your Status

Usualmente, comandos e programas do Linux rodam com o mesmo conjunto de permissões que a pessoa que lança o programa. Quando root executa o comando passwd para alterar 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 que seria ideal é um esquema no qual qualquer pessoa no sistema poderia lançar o programa passwd, mas ter os privilégios elevados do programa passwd. Isto permitiria a qualquer um mudar sua própria senha.

O cenário acima é precisamente o que o bit Set User ID (SUID) faz. Ele executa programas e comandos com as permissões do dono do arquivo, ao invés das permissões da pessoa que lança o programa.

Você está elevando o status do programa

Existe outro dilema, no entanto. A pessoa tem que ser impedida de se intrometer com a senha de qualquer outra pessoa. Linux incorpora o esquema SUID que lhe 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 programa passwd, não no sistema operacional e no esquema SUID.

Programas que rodam com privilégios elevados podem representar riscos de segurança se não forem criados com uma mentalidade de “segurança por projeto”. Isso significa que a segurança é a primeira coisa que você considera, e então você constrói sobre isso. Não escreva o seu programa, e depois tente dar-lhe uma capa de segurança.

A maior vantagem do software de código aberto é que você mesmo pode olhar para o código fonte ou referir-se a revisões de confiança dos seus pares. No código fonte do programa passwd, há verificações, para que você possa ver se a pessoa que executa o programa é root. Diferentes capacidades são permitidas se alguém for root (ou alguém usando sudo).

Este é o código que detecta se alguém é root.

O seguinte é um exemplo no qual isso é levado em conta. Como root pode alterar qualquer senha, o programa não precisa se preocupar com as verificações que normalmente realiza para ver quais senhas a pessoa tem permissão para alterar. Então, para root, ele salta essas verificações e sai da função de verificação.

Com os comandos e utilitários centrais do Linux, você pode estar confiante de que eles têm a segurança embutida neles e que o código foi revisado muitas vezes. Claro, há sempre a ameaça de explorações ainda desconhecidas. No entanto, as correções ou atualizações são rápidas para aparecerem para combater quaisquer vulnerabilidades recentemente identificadas.

É um software de terceiros – especialmente qualquer que não seja de código aberto – você precisa ser extremamente cuidadoso ao usar SUID com. Não estamos a dizer para não o fazer, mas, se o fizer, quer ter a certeza que não vai expor o seu sistema a riscos. Você não quer elevar os privilégios de um programa que não vai se auto-governar corretamente e a pessoa que o executa.

Comandos que usam SUID

A seguir estão alguns dos comandos Linux que usam o bit SUID para dar ao comando privilégios elevados quando executado por um usuário normal:

ls -l /bin/su

ls -l /bin/ping

ls -l /bin/mount

ls -l /bin/umount

ls -l /usr/bin/passwd

Nota 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 para 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, porém, essa permissão não foi dada.

Há três grupos dessas permissões (da esquerda para a direita): aquelas para o dono do arquivo, para membros do grupo do arquivo, e para outros. Quando o bit SUID está definido num ficheiro, um “s” representa a permissão de execução do dono.

Se o bit SUID está definido num ficheiro que não tem capacidades executáveis, um “S” maiúsculo denota isto.

Vamos dar uma vista de olhos a um exemplo. Usuário regular dave digita o comando passwd comando:

passwd

O comando passwd solicita dave a 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 procurar pelo processo passwd. Também usaremos as opções -e (todos os processos) e -f (formato completo) com ps.

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” nelas. É a primeira linha que nos interessa, no entanto, porque é a do processo passwd>dave lançado.

Vemos que o processo passwd corre como correria se root o tivesse lançado.

Configurando o bit SUID

É fácil mudar o bit SUID com chmod. O modo u+s simbólico define o bit SUID e o modo u-s simbólico 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 do usuário real e efetivo (UID).

O UID real pertence à pessoa que lançou o programa. O ID efetivo é a conta 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 ambos configurados para dave. 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 depois verificamos se 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. Vamos executá-lo novamente, mas desta vez vamos executar a cópia na pasta /usr/local/bin:

htg

Even embora dave tenha lançado o programa, o ID efetivo é definido para o usuário root. Então, se mary lança o programa, a mesma coisa acontece, como mostrado abaixo:

htg

O ID real é mary, e o ID efetivo é root. O programa roda com as permissões do usuário root.

RELATADO: Como usar o comando chmod no Linux

O bit SGID

O bit Set Group ID (SGID) é muito parecido com o bit SUID. Quando o bit SGID é definido em um arquivo executável, o grupo efetivo é definido para o grupo do arquivo. O processo corre com as permissões dos membros do grupo do arquivo, ao invés das permissões da pessoa que o lançou.

Ajustamos nosso programa htg para que ele mostre o grupo efetivo, também. Vamos mudar o grupo do programa htg para ser usuário mary do grupo padrão do usuário, mary. Também usaremos os modos u-s e g+s simbólicos com chown para remover o bit SUID e definir o bit SGID.

Para 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 pelos “s” nas permissões do grupo. Note também que o grupo está definido para mary e o nome do arquivo agora está destacado em amarelo.

Antes de executarmos o programa, vamos estabelecer a quais grupos dave e mary pertencem. Vamos usar o comando id com a opção -G (grupos), para imprimir todos os IDs dos grupos. Então, vamos executar 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 lançado por dave, ele está rodando 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, vamos criar um diretório chamado “work,” e depois mudar o seu grupo para “geek”. Vamos então definir o bit SGID no diretório.

Quando usamos ls para verificar as configurações do diretório, vamos também usar a opção -d (diretório) para ver os detalhes do diretório, não o seu conteúdo.

Digitamos os seguintes comandos:

sudo mkdir work

sudo chown dave:geek work

sudo chmod g+s work

ls -lh -d work

O grupo SGID bit e “geek” estão definidos. Estes afectarão qualquer item criado dentro do directório work.

Digitamos o seguinte para entrar no directório work, criamos um directório chamado “demo”, e verificamos as suas propriedades:

cd work

mkdir demo

ls -lh -d demo

Os grupos SGID bit e “geek” são automaticamente aplicados ao directório “demo”.

Digite o seguinte para criar um ficheiro com o comando touch e verifique as suas propriedades:

touch useful.sh

ls -lh useful.sh

O grupo do novo ficheiro é automaticamente definido para “geek”: Como usar o comando chown no Linux

The Sticky Bit

The sticky bit gets its name from its historical purpose. Quando configurado em um executável, ele sinalizou para o sistema operacional que as porções de texto do executável deveriam ser mantidas em swap, tornando a sua reutilização mais rápida. No Linux, o bit sticky afeta apenas um diretório – defini-lo em um arquivo não faria sentido.

Quando você define o bit sticky em um diretório, as pessoas só podem apagar arquivos que pertencem a eles dentro desse diretório. Elas não podem apagar ficheiros que pertencem a outra pessoa, independentemente da combinação de permissões dos ficheiros.

Isto permite-lhe criar um directório que todos – e os processos que iniciam – podem utilizar como armazenamento de ficheiros partilhados. Os arquivos são protegidos porque, novamente, ninguém pode excluir os arquivos de mais ninguém.

Vamos criar um diretório chamado “compartilhado”. Vamos usar o modo o+t simbólico com chmod para definir o bit sticky nesse diretório. Vamos então ver as permissões nesse directório, assim como os directórios /tmp e /var/tmp.

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 conjunto “outro” conjunto de permissões de ficheiros está definido para “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 dono, 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 deveria, teoricamente, ser capaz de fazer qualquer coisa. No entanto, o bit sticky os substitui, e ninguém pode apagar um arquivo que não lhe pertença.

Reminder

O seguinte é 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 bit adesivo em diretórios.
• Se os indicadores “s“, “g“, ou “t” aparecerem em maiúsculas, o bit executável (x) não foi definido.