Permissões especiais: stick e suid bit

No post anterior, falei sobre a umask para definir permissão padrão para criação de novos arquivos e diretórios. E ainda estou devendo as duas permissões especiais stick bit e suid bit.

Estamos lá, felizes da vida como adm da Zion… quando o neo, por descuido apagou um arquivo da trinity:

$ rm report.txt
rm: remover arquivo comum vazio `report.txt’? y
`report.txt’ removido

Hmm… isso não é bom. Usuários apagando arquivos de outros… não é legal. Então, como adm, vamos resolver esse problema usando a permissão especial stick bit.

A permissão stick bit em um diretório faz com que só o dono do arquivo e somente ele apague o arquivo que ele criou! Um exemplo de diretório que usa essa permissão, é o /tmp. Vejam:

# ls -ld /tmp/
drwxrwxrwt 4 root root 4096 Mai 15 21:39 /tmp/

Reparem o ‘t‘ no lugar do ‘x‘ no bloco de permissão de outros… esse ‘t’ indica que a permissão stick bit esta ativa para o diretório… e ai, só quem for o dono do arquivo poderá apagar o arquivo que criou!

No nosso caso, vamos aplicar então, a permissão stick bit ao diretório private… pra evitar que o neo apague outro arquivo da trinity… ou então ela por vingança apague um arquivo do neo 😛 .

# cd /mnt

# chmod +t private/

# ls -l
total 8
drwxr-xr-x 2 root generics 4096 Mai 15 21:21 generics
drwxrws–T 2 root private  4096 Mai 16 11:52 private

Acima, so pedimos para acrescentar a permissão stick bit para todos os blocos de permissão (dono, grupo e outros) utilizando a forma literal… se fosse utilizar a forma octal, o comando seria:

# chmod 3770 private/

Acima, colocamos o 3 porque já existe a permissão de sgid bit que tem o valor 2… e precisamos acrescentar a permissão stick bit que tem valor 1. E temos também que acrescentar as demais permissões que já existiam para o diretório (770).

Vocês devem ter reparado que tem uma diferença entre o stick bit do diretório /tmp e do /mnt/private:

# ls -ld /tmp/
drwxrwxrwt 4 root root 4096 Mai 15 21:39 /tmp/

# ls -ld /mnt/private/
drwxrws–T 2 root private 4096 Mai 16 11:53 /mnt/private/

Essa diferença entre os t’s nos diretórios é que, quando não tem permissão no bloco de outros, a stick bit é indica com o T maiúsculo; e quando existe permissão no bloco de outros, é indicada com t minúsculo.

Vamos ver se isso funciona… a trinity criou o arquivo reports2.txt e o neo, tenta apagar:

$ rm reports2.txt
rm: remover arquivo comum vazio `reports2.txt’? y
rm: imposível remover `reports2.txt’: Operação não permitida

Bem… com isso vimos que a stick bit funciona!

Falando agora sobre a permissão especial suid bit… ela é uma permissão utilizada em arquivos executáveis! Sua função é permitir que um usuário que não seja o dono do arquivo execute como se fosse o dono!

Por exemplo… no terminal que estamos logados como trinity, executamos o comando init, que é o comando que manipula o runlevel do sistema:

$ init
-su: init: command not found

Vejam que a saída do comando é not found… O init é um comando de administração do sistema e a única pessoa que pode executar esse comando é root! Vamos ver como está a permissão do comando init:

# ls -l /sbin/init
-rwxr-xr-x 1 root root 31296 Ago 12  2008 /sbin/init

A permissão padrão desse comando está como 755… vamos adicionar a permissão de suid bit:

# chmod u+s /sbin/init

# ls -l /sbin/init
-rwsr-xr-x 1 root root 31296 Ago 12  2008 /sbin/init

Acima, usei o modo literal para definir a permissão de suid… como é uma permissão para usuários… acrescentamos somente a permissão o bloco de permissão do usuário. Reparem no ‘s’ no local do ‘x’ para execução do comando.

Se fosse para definir a permissão em modo octal, o suid tem valor 4, então ficaria assim:

# chmod 4755 /sbin/init

Sendo que o 4 indica que é permissão do suid, e 755 são as permissões originais do arquivo.

Agora, se a trinity for fazer um teste… se digitar somente o comando init, irá aparecer not found novamente… mas se ela informar o caminho completo do arquivo, vejam o que acontece:

$ /sbin/init
Usage: init {-e VAR[=VAL] | [-t SECONDS] {0|1|2|3|4|5|6|S|s|Q|q|A|a|B|b|C|c|U|u}}b

Hummm… se a trinity executar o comando de forma certa, agora ela também pode manipular o runlevel do sistema…

Vamos voltar o arquivo para a permissão original:

# chmod u-s /sbin/init

# ls -l /sbin/init
-rwxr-xr-x 1 root root 31296 Ago 12  2008 /sbin/init

Usando a forma literal, basta retirar a permissão… se for usar a forma octal:

# chmod 0755 /sbin/init

O exemplo que coloquei, foi apenas para mostrar que arquivos com permissão suid da poderes que talvez não devam ser dados para qualquer usuário… Imaginem, um agente smith, com poderes para manipular o runlevel do sistema?

Mas ainda assim, no sistema existem alguns comandos que precisam de suid e já vem até setado por padrão no sistema. Um exemplo, é o comando passwd que permite que o usuário troque sua própria senha:

# ls -l /usr/bin/passwd
-rwsr-xr-x 1 root root 31640 Nov 22 14:01 /usr/bin/passwd

Se retirarmos o suid desse comando, somente o root poderá trocar a senha dos usuários, o que pode não ser tão conveniente…

Para descobrir quais arquivos estão com suid no sistema, podemos usar o find:

# find / -perm +4000

Com a lista dos comandos, você como adm, pode definir quais arquivos realmente tem necessidade de ter suid, e também se algum usuário mal-intencionado não colocou nenhum arquivo com suid que possa ser prejudicial ao sistema!

É isso aí… com os comandos que vimos nos posts de administração de usuários e permissões… já conseguimos colocar um pouco de ordem no sistema! Até o próximo post!

Anúncios

Permissões especiais no GNU/Linux

Continuando o post anterior sobre administração de usuários, aqui vamos falar sobre permissão especial.

Uma permissão especial, nada mais é do que um complemento das 3 permissões básicas (rwx); esse tipo de permissão afeta arquivos, arquivos executáveis ou diretórios.

As permissões especiais que temos são: stick bit, sgid bit e suid bit.

Assim como as permissões básicas possuem valores (r=4,w=2,x=1), as permissões especiais também possuem valores:

Stick bit – valor 1
Sgid bit – valor 2
Suid bit – valor 4

Vou falar sobre cada uma dessas permissões, dentro do problema que precisamos resolver. No post anterior, vimos que os usuários criaram os arquivos que herdaram as permissões do usuários tanto para dono quanto para grupo.

Então, precisamos de uma permissão especial para o grupo; no caso a SGID. Essa permissão é utilizada em diretórios; sua mágica é fazer com que tudo que for criado dentro do diretório onde definimos SGID seja do grupo do diretório e não do dono que está criando o arquivo!

Isso quer dizer que, quando definirmos o sgid bit no /mnt/private, trinity e neo vão criar os arquivos com o grupo private, pois o diretório private tem esse grupo.

Vamos adicionar então a permissão sgid no diretório:

# cd /mnt/

# chmod g+s private/

# ls -ld private/
drwxrws— 2 root private 1024 2009-03-29 02:12 private/

Acima, apenas acrescentei a permissão ‘s‘ no grupo; e o sistema trocou o x por s na permissão de grupo. Usei o comando chmod com a forma literal; mas se fosse usar a forma octal, o comando seria esse:

# chmod 2770 private/

# ls -ld private/
drwxrws— 2 root private 1024 2009-03-29 02:12 private/

Esse comando faz exatamente o que o comando ‘chmod g+s‘ faz; a diferença entre eles é que, quando uso a forma literal, preciso apenas acrescentar mais uma permissões às que já existem. Agora, quando ajusto as permissões de forma octal, tenho que falar todas as permissões (a permissão especial e as permissões que já existem).

Bem, vamos ver se funcionou! Vamos entrar no terminal onde a trinity está logada e fazer um teste!

$ cd /mnt/private

$ touch sentinelas.txt

$ ls -l
total 0
-rw-r–r– 1 neo     neo     0 2009-03-29 01:51 matrix.txt
-rw-r–r– 1 trinity trinity 0 2009-03-29 02:13 nmap.txt
-rw-r–r– 1 trinity private 0 2009-03-29 02:41 sentinelas.txt

Percebam a diferença! O primeiro arquivo que a trinity criou, o grupo está como sendo o pessoal dela! Depois da modificação que fizemos, agora o grupo do arquivo está como private!

Fazendo um teste com o usuário neo:

$ cd /mnt/private/

$ ls -l
total 0
-rw-r–r– 1 neo     private 0 2009-03-29 02:43 arquiteto.txt
-rw-r–r– 1 neo     neo     0 2009-03-29 01:51 matrix.txt
-rw-r–r– 1 trinity trinity 0 2009-03-29 02:13 nmap.txt
-rw-r–r– 1 trinity private 0 2009-03-29 02:41 sentinelas.txt

$ touch arquiteto.txt

De acordo com a saída do comando ls que o neo executou acima, agora está tudo correto: os arquivos sentinelas.txt e arquiteto.txt foram criados respeitando os donos e mantendo o grupo como sendo private.

Mas… (sempre tem um mas!) quando começamos a falar sobre adm de usuários, dissemos que o private ia ser um diretório público (para trinity e o neo).

E, quando falamos em diretório público, estamos dizendo que as permissões desse diretório será diferente das permissões que vem por padrão quando criamos um diretório (lembra que tivemos que mudar a permissão do private pra trinity e o neo poderem criar os arquivos?).

A permissão padrão do sistema, é chamada de umask. Quando criamos um diretório ou um arquivo, eles já saem criados com uma permissão padrão. O responsável por essa permissão, é nada mais nada menos do que a umask.

Se analisarmos as permissões dos arquivos que os usuários criaram, eles estão vindo com a permissão padrão… o dono pode ler e escrever, mas o grupo só pode ler!

Isso quer dizer que, mesmo que o usuário faça parte do grupo private, não pode escrever no arquivo, uma vez que os arquivos criados estão com permissão 644! Bem… precisamos corrigir isso!

No próximo post, vou comentar sobre a umask para resolver esse problema da permissão de escrita para grupo! Até la! 😀