Qual vantagem de segurança os privilégios de execução têm?

Digamos que algum administrador de sistema não tenha problemas com a leitura dos arquivos em/sbin, mas não deseja que eles os executem. Considere por exemplo

Então esse administrador está perdido. Qualquer usuário pode

cat /sbin/program > ~/program # only needs read privileges
chmod o+x ~/program
~/program

Então, isso não faz sentido. Duas exceções:

1. o original pode ter o bit suid definido.
2. o original pode ter xattrs de segurança que o restringem ainda mais (SELinux, Apparmor, outros LSMs…)

A segunda coisa não será relevante. Essa é uma restrição adicional em relação à execução de uma cópia do executável como usuário.

A primeira coisa: sim, isso é um problema. Mas a solução é quase sem exceção afastar-se dos binários setuid, em direção a mecanismos onde um processo não ganha privilégios que o usuário inicial não possui. (Você pode considerar regras sudo complexas sendo preferidas como uma medida provisória questionável, o que é pelo menos vantajoso porque você pode pelo menos ajustar quem pode executar o que como usuário diferente por meio de /etc/sudoers. É muito sujeito a erros, imho.)

Tais mecanismos são bastante difundidos em sistemas operacionais de "interface humana" não-GNU/BSD (ou seja, Android, Windows, MacOS, iOS, MBOS, para citar os poucos que me vêm à mente): Você nunca inicia uma "modificação do sistema" comando como um usuário sem privilégios que de repente obtém acesso root, porque isso é apenas um convite para encontrar bugs que permitem que você faça aquele programa fazer o que você quiser (uma lista com curadoria de programas *nix que você pode fazer executar o que quiser executar ).
Por exemplo, uma coisa popular é que em servidores de computação científica, os clientes de backup recebem suid – para que um usuário normal possa executar um backup de todo o seu ambiente, para um serviço de armazenamento que não pode acessar regularmente. Ótima ideia, além de poder especificar o compressor na linha de comando, que então roda como root. Use um script que gere um servidor telnet e passe da entrada para a saída descompactada; pronto, aí está a sua porta dos fundos.

Em vez disso, há um deamon de gerenciamento de sistema, gerado pelo processo init (~equivalente), para o qual o usuário sem privilégios envia solicitações muito bem definidas, que verifica internamente os privilegiados (normalmente, usando um mecanismo centralizado para isso) e, em seguida, faz o operação pré-configurada.

Isso é perfeitamente ilustrado pelo seu exemplo /sbin/poweroff. Para distribuições Linux hoje em dia, desligar é um processo complicado – você precisa verificar se o usuário solicitante tem o direito de fazer isso, você precisa verificar se ninguém mais está logado, você precisa desmontar todas as coisas que o usuário logado podem ter se montado, incluindo sistemas de arquivos de rede, interrompido seus daemons de usuário (do emacs -d para o cliente Steam!), salvo seu trabalho, fechado seus programas aplicativos, desconectado deles, iniciado a sequência de desligamento, derrubado coisas no ordem correta (não deve desligar a rede enquanto a montagem NFS do sistema ainda está sincronizando dados!)…
Eu não vi um sistema Linux multiusuário onde /sbin/poweroff fosse apenas um script de desligamento suid em talvez uma década. Tenho certeza de que os BSDs têm o mesmo problema e o tratam de maneira semelhante. Então, se esse problema existe, é porque o administrador deixou o sistema em meados da década de 1990. É hora de fazer algo sobre isso!

A área de usuários do desktop Linux há muito mudou nessa direção. Seu desktop Linux não chama mountmais um Suid para montar o pendrive que você acabou de conectar e deseja abrir como usuário sem privilégios, ele solicita acesso de um daemon de gerenciamento de disco. Funciona lindamente (e, tendo estado lá, muuuito mais confiável, melhor e menos sujeito a erros que o Linux do final dos anos 90/início dos anos 2000).

Então, voltando à sua pergunta:

Qual é o objetivo do privilégio de execução então?

Ele permite restringir quais arquivos são imediatamente executáveis. Como dito, isso faz diferença na presença de SUID e outros mecanismos de segurança vinculados a arquivos; faz diferença se você pode usar algo como intérprete para um formato de arquivo, e diz ao seu shell que quando você digita "nano", você deseja que /usr/bin/nano seja executado, e não o arquivo de texto chamado " nano" que acabou em algum outro lugar no seu caminho.

O bit de permissão de execução em arquivos não é realmente um recurso de segurança, trata-se principalmente de distinguir arquivos que são executáveis ​​​​de arquivos que não são.

A segurança da execução é controlada por outros recursos do sistema. Por exemplo, os administradores que não desejam permitir que os usuários executem binários arbitrários podem garantir que qualquer diretório no qual os usuários possam gravar esteja em um noexecponto de montagem. O escalonamento de privilégios, como binários setuid, depende de propriedades que são perdidas quando os binários são copiados: o bit setuid, entradas em arquivos de configuração como sudoersou pkexecperfis, etc.

Qual é o objetivo do privilégio de execução então?

Principalmente porque evita a execução inadvertida de arquivos que na verdade não contêm código executável ou scripts. Arquivos como README.txt.

Sua observação de que negar a permissão de execução de um arquivo de programa e permitir que os usuários o leiam é inútil é absolutamente correta: qualquer coisa que o usuário possa ler, ele pode copiar; e a nova cópia será deles para definir as permissões conforme acharem adequado.

Mas em algumas situações, você pode desejar conceder o privilégio de execução sem o privilégio de leitura correspondente. Um exemplo podem ser programas que possuem privilégios setuid/setgid atribuídos a eles. Alguns sistemas Unix proprietários (e alguns guias de proteção) podem definir as permissões de, por exemplo , /bin/passwdpara ---s--x--x, proprietário root, para desencorajar os usuários de tentar encontrar pontos fracos no binário setuid usando um desmontador ou outras ferramentas de depuração nele.

Em sistemas operacionais de código aberto como Linux e BSD, esse microgerenciamento de permissões pode ser considerado desnecessário, uma vez que o código-fonte desses programas setuid/setgid está disponível gratuitamente para qualquer pessoa.

Mesmo assim, o kernel e os drivers ainda determinam quais operações exigem mais privilégios do que os usuários normais. Ter acesso a uma cópia executável /sbin/ifconfigcomo um usuário normal pode permitir que você visualize as configurações de rede do sistema, mas se você tentar alterá -las, tudo o que conseguirá será uma mensagem de erro "Permissão negada".

E se você tentar copiar um binário setuid ou setgid, descobrirá que muitos drivers de sistema de arquivos removerão automaticamente esses bits de permissão ao gravar em um arquivo, portanto, esses bits precisarão ser explicitamente colocados de volta após a conclusão da gravação. mas sem privilégios de root (ou equivalentes), você absolutamente não pode produzir um novo arquivo que pertenceria a alguém que não seja sua própria conta de usuário , portanto, mesmo que você pudesse preservar ou adicionar novamente o bit setuid, a cópia não seria setuid root, mas setuid yourself. Isso não lhe daria nenhum privilégio que você ainda não tivesse, e tê-lo por perto poderia permitir que outros usuários se passassem por você .

O mesmo se aplica ao bit setgid: se você tentar adicionar um bit setgid a um arquivo pertencente a um grupo do qual sua conta de usuário ainda não é membro, a solicitação para adicionar um bit setgid será ignorada silenciosamente.

Ver man 2 chmod:

Se o processo de chamada não for privilegiado (Linux: não possui a capacidade CAP_FSETID) e o grupo do arquivo não corresponder ao ID de grupo efetivo do processo ou a um de seus IDs de grupo suplementares, o bit S_ISGID será desativado, mas isso não fará com que um erro seja retornado.