Umask 002 security risks?

[AlexSanchezSTHLM]

Hi,

I have a server that is shared (some directories) by multiple users belonging to a common group. The shared directories have the GID set to the common group as well as group write permission, so when a privileged user creates a file a directory the group ownership is propagated. However, because of the default umask of 022 in FreeBSD, the new files and directories doesn't get the expected permissions (group write).

The proposed solution I found is to set the umask to 002, but I can't find anything about the security implications and consequences. I would like know if there are any risks setting the umask 002 system wide.

When a new user is added, the user get a "private" primary group (same name and the GID is the same as the UID). So the way I see it it's ok unless you explicitly change the ownership of a directory to a common group, in that case all containing files and directories will be writeable by all users in that group.

Also, I have read that some Linux distributions have a system default umask of 002...

Note: I'm changing the default umask in /etc/login.conf for classless users, so root's umask is not affected.

 

[asteriskRoss]

Your solution of changing the umask is sensible and what group permissions are meant to be all about. You asked about security implications. It is worth considering:

• If your users have shell access (you didn't mention whether it was just a network file share or similar), whether your users will be creating any executables in the shared directories. A malicious user could change the functionality of a shared executable so that it does something other than the user running it expects (a trojan).
• Again, if your users have shell access, whether you'll be using any executables that have the Set UID bit set (see section 4.4 of the handbook) in the shared directories, to allow a process to run as a different effective user, with the privileges of that user. If the file is owned by the group, a malicious member of that group could change the contents of the executable and run their own commands as the effective user, potentially escalating her/his privileges.
• Even non-executables are a potential threat, as a shared file could be carefully altered by a malicious user to exploit a vulnerability in software used to process it, such that when another user opens the file with the vulnerable application, the malicious user's code is executed.

In real life, users need to share files and sometimes applications really do need to run as a different effective user, so I wouldn't lose sleep. Whilst your server would be more secure if it didn't have any pesky users, it probably wouldn't be very useful to you.

 

[asteriskRoss]

A very belated afterthought: You didn't mention what your requirements were for "other" users (those users who do not own the files and are not members of the group that owns the files). If you don't expect such users to typically need read and execute permissions by default, you might want to consider a stricter umask of 007.