Por que o su world é executável?

Eu tenho um servidor sem cabeça conectado remotamente por vários usuários. Nenhum dos outros usuários está no arquivo sudoers, portanto, eles não podem obter o root via sudo. No entanto, como as permissões suestão disponíveis, -rwsr-xr-xnão há nada que as impeça de tentar fazer força bruta na senha de root.

Alguém poderia argumentar que, se um usuário souber a senha root, poderá comprometer o sistema de qualquer maneira, mas não acho que seja esse o caso. O OpenSSH está configurado com PermitRootLogin noe PasswordAuthentication no, e nenhum dos outros usuários tem acesso físico ao servidor. Até onde eu sei, o mundo executar permissão /usr/bin/sué a única avenida para os usuários que tentam obter root no meu servidor.

O que é mais intrigante para mim é que nem parece útil. Ele me permite executar sudiretamente, em vez de precisar sudo su, mas isso não é um inconveniente.

Estou negligenciando alguma coisa? O mundo executa permissão suapenas por razões históricas? Existem desvantagens na remoção dessa permissão que ainda não encontrei?

Um ponto que está faltando na resposta de ilkkachu é que elevar para a raiz é apenas um uso específico su. O objetivo geral do su é abrir um novo shell na conta de login de outro usuário. Esse outro usuário pode ser root(e talvez seja o mais frequentemente), mas supode ser usado para assumir qualquer identidade que o sistema local possa autenticar.

Por exemplo, se estou logado como usuário jime quero investigar um problema mikerelatado, mas que não consigo reproduzir, posso tentar fazer login como mikee executar o comando que está causando problemas.

13:27:20 /home/jim> su -l mike
Password:(I type mike's password (or have him type it) and press Enter)
13:27:22 /home/mike> id
uid=1004(mike) gid=1004(mike) groups=1004(mike)
13:27:25 /home/mike> exit  # this leaves mike's login shell and returns to jim's
13:27:29 /home/jim> id
uid=1001(jim) gid=1001(jim) groups=1001(jim),0(wheel),5(operator),14(ftp),920(vboxusers)

Usar a -lopção de sufaz com que simule um login completo (por manpágina).

O acima exposto requer conhecimento da mikesenha de, no entanto. Se eu tiver sudoacesso, posso efetuar o login mikemesmo sem a senha dele.

13:27:37 /home/jim> sudo su -l mike
Password:(I type my own password, because this is sudo asking)
13:27:41 /home/mike>

Em resumo, o motivo pelo qual as permissões no suexecutável são as que você mostra é porque sué uma ferramenta de uso geral disponível para todos os usuários no sistema.

Historicamente (em unidades não GNU), não era, ou pelo menos verificava manualmente se você estava em um grupo chamado "roda" com permissão su. A versão GNU do sunão reproduziu essa funcionalidade devido à ideologia do RMS sobre controle de acesso na época:

Why GNU `su' does not support the `wheel' group
===============================================

   (This section is by Richard Stallman.)

   Sometimes a few of the users try to hold total power over all the
rest.  For example, in 1984, a few users at the MIT AI lab decided to
seize power by changing the operator password on the Twenex system and
keeping it secret from everyone else.  (I was able to thwart this coup
and give power back to the users by patching the kernel, but I wouldn't
know how to do that in Unix.)

   However, occasionally the rulers do tell someone.  Under the usual
`su' mechanism, once someone learns the root password who sympathizes
with the ordinary users, he or she can tell the rest.  The "wheel
group" feature would make this impossible, and thus cement the power of
the rulers.

   I'm on the side of the masses, not that of the rulers.  If you are
used to supporting the bosses and sysadmins in whatever they do, you
might find this idea strange at first.

Você pode encontrar muito mais sobre o assunto pesquisando no Google "wheel group rms" ou similar.

No entanto, como as permissões suestão disponíveis, -rwsr-xr-xnão há nada que as impeça de tentar fazer força bruta na senha de root.

Sim. Assumindo o seu sistema Linux habitual, o pam_unix.somódulo atrasa uma tentativa de autenticação com falha em ~ dois segundos, mas acho que não há nada para interromper as tentativas simultâneas.

As tentativas com falha são registradas, é claro:

Aug 16 22:52:33 somehost su[17387]: FAILED su for root by ilkkachu

Forçar brutalmente uma senha deve aparecer com destaque nos logs, se você tiver algum tipo de sistema para monitorá-las. E se você tem usuários locais não confiáveis, talvez deva. Usuários locais não confiáveis ​​também podem tentar usar quaisquer explorações de escalonamento de privilégios somente locais e são muito mais comuns que escalonamento de privilégios remotos.

O que é mais intrigante para mim é que nem parece útil.

Claro que é útil, permite que você se eleve root, se você souber a senha.

Ele me permite executar sudiretamente, em vez de precisar sudo su, mas isso não é um inconveniente.

sudo sué um pouco redundante. Não há necessidade de usar dois programas que permitem executar programas como outro usuário, um é o suficiente. Basta usar sudo -iou sudo -s(ou sudo /bin/bashetc.) se você quiser executar o shell.

Estou negligenciando alguma coisa? O mundo executa permissão para o su apenas por razões históricas?

Veja acima. Bem, nem todos os sistemas têm sudocomo alternativa, não tenho certeza se você considera isso histórico.

Existem desvantagens na remoção dessa permissão que ainda não encontrei?

Na verdade, não, tanto quanto eu sei. Eu acho que alguns sistemas foram suconfigurados para que apenas membros de um grupo específico (" wheel") possam executá-lo. Você pode fazer o mesmo sudose quiser ( chown root.sudousers /usr/bin/sudo && chmod 4710 /usr/bin/sudo).

Ou você pode simplesmente remover um ou ambos os programas, se não precisar deles. Embora no Debian, suvenha com o loginpacote, provavelmente não é uma boa ideia remover o pacote como um todo. (E o emparelhamento logine sujuntos dessa maneira parece um pouco histórico.)

Você já tem boas respostas, mas há uma parte da sua postagem que elas não abordam.

Até onde eu sei, o mundo executar permissões em / usr / bin / su é a única avenida para usuários que tentam obter root no meu servidor.

Essa é uma suposição perigosa. Se você definiu uma boa senha para root, na maioria dos casos é muito mais provável que uma escalação de privilégios seja bem-sucedida devido à exploração de um bug no kernel ou em um binário setuid (é claro, você também pode remover o setuid pouco disso, mas passwdé setuid, e se você deseja alta segurança, também deve oferecer isso aos seus usuários, e negar a eles a opção de alterar a senha deles não é compatível com isso).

su precisa ser executável mundialmente para que todos possam executá-lo. Em muitos sistemas, ele pode ser usado para mudar para outro usuário, fornecendo sua senha.

Se você está preocupado com alguém que força a senha de root, basta desabilitá-la. (invalide o hash para que nenhuma senha possa corresponder a ele)

Eu não sei sobre o consenso, mas consideraria a possibilidade de efetuar login como root diretamente, um problema de segurança por si só.

As outras respostas estão corretas, dizendo "su" permite que você faça login em contas que não sejam root.

Uma observação sobre "sudo su" embora. Na verdade, isso permite que você faça login na conta root sem saber a senha root. Você precisa saber a senha da conta com a qual você executa o sudo, além de ter essa conta no arquivo sudoers.