Permissões SUID - Qual é o correto?

2

Tentando proteger um servidor Linux e ter pouca experiência com o SUID. Depois de executar

find / -perm +4000

muitos programas foram descobertos. Eu vi conselhos conflitantes aqui e aqui sobre o que deve ser ativado e não.

SUID ativado em /bin/su
/usr/bin/passwd
/usr/bin/gpasswd
/sbin/unix_chkpwd

SUID desativado
/usr/bin/crontab
/usr/bin/newgrp
/bin/ping
/bin/ping6
/bin/umount
/bin/mount
/usr/bin/chsh
/usr/bin/chfn
/usr/libexec/pt_chown
/usr/bin/sudo
/usr/bin/sudoedit
/usr/bin/chage
/usr/sbin/userhelper
/usr/sbin/usernetctl
/usr/sbin/suexec

NÃO SEGURO
/usr/libexec/openssh/ssh-keysign
/sbin/pam_timestamp_check

O servidor hospedará vários sites com poucos usuários de Linux / SFTP. O que deve mudar? Além disso, como devo testar?

    
por csi 13.02.2013 / 15:29

3 respostas

3

Eu pessoalmente não me incomodaria, pois os programas que você listou são normalmente considerados seguros e protegidos. E, por exemplo, sudo sem o conjunto de bits suid não faz sentido. O mesmo vale para chsh chfn etc. Se você realmente deseja proteger seu servidor, eu apenas daria aos seguintes executáveis suid permissões:

  • ping / ping6 por motivos de diagnóstico.
  • suexec para executar scripts cgi sob diferentes usuários
  • su ou sudo
  • pt_chown se você não tiver devpts

Você pode remover o bit suid de ssh-keysign , pois ele é usado somente para autenticação baseada em host, de acordo com link

Você também deve garantir que seus usuários não obtenham acesso ao shell e tenham seu diretório chrooted.

Se você realmente deseja proteger seu servidor, considere investigar o SELinux .

    
por 13.02.2013 / 15:55
5

Deixe sua distribuição fazer o que quiser, a menos que tenha certeza de que sabe o que está fazendo. O fato de você precisar fazer essa pergunta mostra que você não sabe o suficiente. Então saia bem sozinho.

Quais programas precisam ser setuid depende de como as coisas estão configuradas na sua distribuição. Por exemplo, o Fedora substituiu a maioria dos usos de setuid por setcap . Por exemplo, o ping precisa da capacidade CAP_NET_RAWIO para poder abrir soquetes brutos; pode obtê-lo sendo setcap CAP_NET_RAWIO (melhor isolamento de privilégio) ou sendo setuid root (o método tradicional, que não requer executáveis setcap).

Os programas que você lista são projetados para serem executados por usuários comuns, mas requerem privilégios extras para funcionar. Se você remover seu bit setuid, você irá quebrar seu sistema. Por exemplo, ping simplesmente parará de funcionar (a menos que você esteja logado como root). Você poderá se tornar root com su , mas não com sudo , o que anula o ponto inteiro de sudo . Os usuários não poderão definir crontabs. E assim por diante.

Em um servidor dedicado, algumas das coisas que você quebrou podem não importar. Mas você só deve alterar os padrões da distribuição se souber que está fazendo a coisa certa, e não o contrário. Lembre-se de que a disponibilidade faz parte da segurança. Se você se desconectar do servidor ou não conseguir diagnosticar e reparar problemas, você quebrou sua própria segurança.

    
por 14.02.2013 / 01:15
1

O selinux cuidará muito disso (nos sistemas que o possuem). Então, se você estiver usando o selinux, eu deixaria todas as coisas setuid sozinhas, não deveria ter mais permissões do que a política do selinux daria.

    
por 14.02.2013 / 14:54