Nota: recomendo atualmente o AppArmor, mas manterei este artigo por questões históricas. Até porque, o blog dele não está mais disponível no endereço que eu conhecia.

Para quem é da área de segurança de informações, eis um exercício interessante para os sistemas que possuem suporte ao POSIX capabilities. Ele foi originalmente publicado na Linux Magazine de novembro de 2008 e o autor é o Marlon Luís Petry.

Primeiro verificamos então se o suporte foi habilitado no kernel:

$ zgrep '\(XATTR\|CAPA\)' /proc/config.gz

Caso dê algum resultado diferente, veja se o config.gz realmente foi habilitado (o que foi o meu caso):

$ cat /boot/config-$(uname -r) | grep -i ikconfig

# CONFIG_IKCONFIG is not set

Que azar… Mas felizmente havia o suporte necessário compilado (descobri na base do método empírico, conhecido também como tentativa-e-erro). Sendo assim, para quem usa Debian, Ubuntu e derivados, é necessário instalar o pacote libcap2-bin:

$ sudo apt-get install libcap2-bin

Agora que já estamos com tudo pronto, vamos a um exemplo: o ping.

$ ls -l /bin/ping
-rwsr-xr-x 1 root root 36912 2007-12-10 17:03 /bin/ping

Ele tem o SUID bit ativado (note o “s” em suas propriedades). Agora é hora de “extirparmos” o dito cujo:

$ sudo chmod u-s /bin/ping
$ ls -l /bin/ping
-rwxr-xr-x 1 root root 36912 2007-12-10 17:03 /bin/ping

E fazer um teste, para verificar se o ping ficou “aleijado”.

$ ping 127.0.0.1
ping: icmp open socket: Operation not permitted

Opa! Mas e agora? Como fazemos para que o ping funcione sem o SUID bit ativado? Simples:

$ sudo setcap cap_net_raw=ep /bin/ping

E lá vamos nós de novo…

$ ping -c 4 127.0.0.1
PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data.
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.083 ms
64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.065 ms
64 bytes from 127.0.0.1: icmp_seq=3 ttl=64 time=0.083 ms
64 bytes from 127.0.0.1: icmp_seq=4 ttl=64 time=0.081 ms
--- 127.0.0.1 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3001ms
rtt min/avg/max/mdev = 0.065/0.078/0.083/0.007 ms

Agora, vamos fazer um “turismo” no sistema de arquivos e descobrir o que temos com o SUID bit ativado:

$ sudo find / -type f \( -perm -004000 -o -perm -002000 \)  -exec ls -lg {} \;
-rwsr-xr-x 1 root root 36456 2009-04-04 02:50 /bin/su
-rwsr-xr-x 1 root root 82064 2009-02-18 18:42 /bin/mount
-rwsr-xr-x 1 root root 32704 2007-12-10 17:03 /bin/ping6
-rwsr-xr-x 1 root root 59160 2009-02-18 18:42 /bin/umount
-rwsr-xr-x 1 root root 29808 2009-03-05 19:53 /bin/fusermount

A lista é enorme, então deixei apenas os cinco itens acima como exemplo. Seria interessante que todas as distribuições tivessem esta segurança a mais por padrão.

Mas então alguém pergunta: e como eu sabia o que habilitar pelo comando setcap? É necessário carregar-se um módulo capable_discovery e então verificar-se o /var/log/messages:

$ modeprobe capable_discovery catch=ping
$ tail -f /var/log/messages | grep ping

No caso do ping, irá aparecer:

localhost Module capable_discovery inserted for discover the capabilities of "ping" process
localhost capability 21=CAP_SYS_ADMIN for ping
localhost capability 13=CAP_NET_RAW for ping
localhost capability 7=CAP_SETUID for ping

Há um exemplo interessante no blog do Marlon sobre o que pode acontecer quando se usa o SUID bit.

  • Share/Bookmark