Por que um diretório gravável de grupo é considerado inseguro?

Question

Mais especificamente, por que o daemon de libslack considera os arquivos que estão sendo executados em um diretório gravável de grupo como "inseguro"? Se você puder me dar uma explicação de por que os diretórios graváveis em grupo são considerados inseguros em um sentido geral, isso também seria bom.

Desculpe, aparentemente isso não era claro. Na página man do daemon do libslack, ele afirma:

-U, --unsafe

Allow reading an unsafe configuration file and execution of an unsafe executable. A configuration file or executable is unsafe if it is group or world writable or is in a directory that is group or world writable (following symbolic links). If an executable is a script interpreted by another executable, then it is considered unsafe if the interpreter is unsafe. If the interpreter is /usr/bin/env (with an argument that is a command name to be searched for in $PATH), then that command must be safe. By default, daemon(1) will refuse to read an unsafe configuration file or to execute an unsafe executable when run by root. This option overrides that behaviour and hence should never be used.

No final, afirma que essa opção (a opção insegura) deve nunca ser usada aparentemente / presumivelmente devido a preocupações de segurança.

Pessoalmente, não consigo realmente pensar no que seria inerentemente inseguro sobre como daemonizar algo que reside em um diretório gravável de grupo.

Não vejo por que a minha pergunta foi colocada em espera porque parece uma questão bastante direta para mim, para qualquer um que realmente a leia, mas aqui está uma tentativa de escrevê-la com mais clareza.

Por que é considerado inseguro para um arquivo ter um diretório em seu caminho que seja gravável em grupo?

Para mim, isso é mais especificamente com relação ao daemon libslack, mas eu vi vários outros pacotes sinalizando o mesmo cenário como inseguro também, então se você puder me fornecer algumas informações sobre que tipo de problemas de segurança eu poderia esperar para mim correndo - apesar do aviso - daemon com a bandeira insegura, isso seria maravilhoso.

    

Answer 1

Do manual do sendmail / Majordomo:

2.4.1. Consequences of Unsafe Group Writes

If a user has write permission to access an aliases file, she should be a trusted user. By putting an entry into the aliases file (such as the one used to execute wrapper) a user can execute any program with the privileges of Sendmail (daemon or, in older versions, root). This gaffe would allow people to remove or change the permissions of files that belong to daemon (using the rm or chmod commands in the aliases file). To some extent, this possibility is avoided by using smrsh; however, one must still be careful as to what files are in the /etc/smrsh/ directory.

Another important security issue is that the user who can access the aliases file can append or write to files that belong to daemon by using file redirection (a >> or > instead of a |). Even so, this breach too can be countered by adding a line to the sendmail.cf file limiting what files can be written to through the aliases file.

< .. >

In the case of include or .forward files, commands or redirections are run as the user who owns the file. Therefore, if a file is group writable, a member of the group can execute commands as the user who owns the file. In other words, any user in the group could execute commands as that user. However, since the user is created without a shell, commands or redirections will not be processed in include files owned by that user.

4.2. Consequences of Unsafe Group Writable Directory Paths

If a user has group write permission to a directory, for example /etc/, the user could simply move any file and create a new one in its place. An attack might go something like this

[user@system etc]$ mv aliases ...
[user@system etc]$ vi aliases

The user can then make her own aliases! This attack, however, could be prevented by Sendmail's security checking for unsafe group writable paths. Such an attack also would work with include and .forward files having unsafe paths.

Fonte .

Este manual explica isso muito bem e a mesma lógica se aplica a muitos outros softwares: lembre-se de que você está usando um sistema multiusuário, mesmo que você seja o único usuário desse sistema. E em um sistema multiusuário, um usuário precisa ser protegido de outros usuários.