Why is a group writable directory considered unsafe?

More specifically, why does libslack's daemon consider files that are being executed in a group writable directory to be "unsafe"? If you can give me an explanation of why group writable directories are considered unsafe in just a general sense that would be nice too.

Sorry, apparently this was too unclear. In libslack's daemon man page it states:

-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.

At the end it states that this option (the unsafe option) should never be used apparently/assumably due to security concerns.

I personally can't really seem to think of what would be so inherently unsafe about daemonizing something that resides within a group writable directory.

I don't see why my question was put on hold either because it seems like a rather straight-forward question to me for anyone that actually read it but here is an attempt to write it out more clearly.

Why is it considered unsafe for a file to have a directory in its path that is group writable?

For me this is more specifically in regards to libslack's daemon but I have seen multiple other packages flag the same scenario as unsafe as well, so if you could provide me with some information as to what type of security issues I could expect due to me running--despite the warning--daemon with the unsafe flag, that would be wonderful.

1 Answer

From the manual of 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.

Source.

This manual explains it pretty well and the same logic applies to many other pieces of software: mind that you are using a multi-user system even though you might be the sole user of that system. And on a multi-user system a user needs to be protected from other users.