Effects of tightening umask

Support for security such as Firewalls and securing linux
Post Reply
Posts: 47
Joined: 2019/07/13 22:19:14

Effects of tightening umask

Post by sawozny » 2019/09/13 18:31:56

Hello CentOS gurus! :)

I'm investigating tightening the umask on my CentOS 7.6 Min Install to 027. The idea came from CIS guidance and it doesn't sound like a bad idea to me that files be created with no "group" write permissions and no "other" permissions at all unless explicitly requested by the process creating the file, but I've had a career full of events that shouldn't have been a problem and ended up being so due to things I didn't know about. :) So, does anyone know of any problems with upping umask to 027?

Also, on the topic, while looking for places to set the umask, I found the following logic in /etc/profile and /etc/bashrc

Code: Select all

if [ $UID -gt 199 ] && [ "`/usr/bin/id -gn`" = "`/usr/bin/id -un`" ]; then
   umask 002
   umask 022
This says to me for UIDs 200 and over when your group name matches your user name (in other words, a "normal" rather than a "system" user account) use a umask of 002, otherwise use a umask of 022. Does anyone know where the rationale for this comes from? I know the UID range for user accounts has increased over time (they started at 100 when I first started using UNIX in college and I think the increase from 500 to 1,000 has only been in the last 10 years or so) so I'm wondering if the selection of 200 as the dividing line between "normal" and "system" user accounts is an outdated artifact that needs an update at some point, but I can't think of a use case where it makes sense to use a more restrictive umask in regards to group rights for a "system" account. Or is there?

In my research so far, it seems like the umask value is a last-ditch backstop and most grown-up programs set DAC rights to exactly what they want so they don't have to rely upon inconsistent umask values from install to install, but maybe I'm missing something significant and obvious here so I thought I'd ask the thoughts of the group.

Are you for or against tightening the umask and do you do so differently based upon the nature of the account? Alternatively, are you aware of any horror stories from straying from the default umask values in any way?

Any feedback would be greatly appreciated.



User avatar
Forum Moderator
Posts: 30179
Joined: 2009/09/24 10:40:56
Location: Brighton, UK

Re: Effects of tightening umask

Post by TrevorH » 2019/09/13 19:27:38

The choice of 200 looks dated to me. Perhaps trawl bugzilla.redhat.com looking for similar reports?
CentOS 6 died in November 2020 - migrate to a new version!
Info for USB installs on http://wiki.centos.org/HowTos/InstallFromUSBkey
CentOS 5 is dead, do not use it.
Full time Geek, part time moderator. Use the FAQ Luke

Posts: 47
Joined: 2019/07/13 22:19:14

Re: Effects of tightening umask

Post by sawozny » 2019/09/13 23:33:41

Yeah, I thought it looked dated, too. I didn't see anything in RH Bugzilla about it, so I might post there and see if they have anything to say.

Also, in the "Murphy's Law" category, I found an issue I created after changing umask to 027. As part of spinning up images with KVM/qemu, I created an iso directory in /var/lib/libvirt for the storage of ISO images which, the first time I did it using OS default umasks, created a directory where "other" could list the contents. Thinking "well, I'm only going to need access to this ISO as root when I sudo virt-install or sudo virsh things" I figured this new DAC setting on the new ISO directory prohibiting list access to "other" wasn't going to be a big deal.

However, when I tried to do a sudo virt-install using an ISO file I put in that directory as a --location my installs began failing. Suspecting a rights problem, it appears that when you do a sudo virt-install, part of the process is to chown the ISO file you're using to qemu:qemu which is all fine if everything is running as root, but apparently qemu needs access to that ISO to do part of the process (probably why virt-install changes the ownership) and when that file is in a 750 DAC directory, that brings the whole process to a crashing halt.

The fix was easy. As there's nothing security sensitive about ISO images, I make the iso directory DAC 755 and the install went just fine. But it was funny that the exact thing I was concerned would happen did just that the day I started musing about it.

My present feeling is to soldier through with the 027 umask, but I'm wondering what else will pop up. If anyone can lend the benefit of their experience, I would appreciate it. :)



Posts: 2019
Joined: 2015/02/17 15:14:33
Location: Bulgaria

Re: Effects of tightening umask

Post by hunter86_bg » 2019/09/14 19:12:35

I don't thing that umask will bring any benefits from security point of view.
Have you thought about SELINUX being tuned up?
For example , you can map each user to a specific SELINUX user (based on user's role) and this is way more secure and in control.

Posts: 47
Joined: 2019/07/13 22:19:14

Re: Effects of tightening umask

Post by sawozny » 2019/09/14 22:13:02

Your point of what possible benefit this change can bring from a security point of view continues to vex me. I’ve tried laying out the pros and cons and have come up with this:

For making the change:
• More secure. Giving “other” read/write (and “group” write, if you’re an end user) DAC rights is an intentional act, rather than a default. The guidance phrases it as ensuring that users make a conscious choice about their file permissions.
• Prevents, by default, giving more access than may be needed when creating files and directories by hand. Even if this doesn’t buy a LOT, it falls into the defense in depth / minimize the attack surface / etc… justification bucket.
• The problem I had with virt-install could have been easily avoided if I had looked at the other directories in the folder I was creating the sub in and set the permissions to match after I made the umask change. I did it with the SELinux context and I SHOULD have done so with the DAC, but I didn’t and THAT is what bit me. Failure to think, rather than a true unknown.
• This has been in CIS guidance for a while. If this was a really terrible idea, I’d have found more cautionary tales while googling like I did with disabling IPv6. So this implies most grown-up programs explicitly set the DAC on any files they produce or this variable would have caused problems if even a small number of sysadmins made this change over the years to follow guidance / appease an auditor, etc...

Against making the change:
• Deviating from operating system defaults can bite you in the ass in all manner of unpredictable ways. I found this, myself, when I created the iso directory under /var/lib/libvirt and the rights prevented the qemu user from getting to the ISO file which I had no way of knowing was even necessary as I thought the whole process ran as root when I sudo’ed the virt-install command.
• Lack of feedback in the forums and generally on-line could indicate this is a complicated issue with most people not taking a side and complexity is the enemy of security.
• SELinux is already on the case and protecting the system in more advanced ways than the umask change ever could. As a matter of fact, when I had my problem, SELinux behaved just fine and it was the new DAC default that was the problem.
• The threat this guidance seems to be most protecting against is that of other users getting access to files they shouldn’t, accidentally. This seems like it would most be a threat in a multi-user system with multiple users who did not have the same motivation, but in a series of systems, each with a single purpose, and all actual users being from the same organization, this doesn’t add as much as the security threat model for a truly “shared” environment.
• This can be overridden by a .bashrc or .profile directory by anyone who wants to so this is a completely discretionary control. Again, SELinux is what’s really going to protect me.

So the argument for making this change is a very small increase in security posture that can be easily overridden in a variety of ways (both for better and for worse) against the unknown of changing OS defaults in a system where a more advanced security system is already providing better protection. In my case, this is all in an operational use context that isn’t a shared environment where this change would be of the most benefit making the already thin security justification even thinner. What really remains is the unknown factor of whether or not defending against that threat could save my ass someday or needlessly bite me in it and I don’t think I can ever really answer that question. Bruce Schneier is famed for saying security is all about trade-offs but in this instance, if I was to flip a coin, this choice seems so evenly balanced I think it might land on its side just to spite me... :)

Posts: 148
Joined: 2019/01/15 20:00:28

Re: Effects of tightening umask

Post by ron7000 » 2019/10/07 15:49:58

the effects... a false sense of security and headache on your part.

any user can for themself do a umask 000 and override the default umask in effect (for them) in /etc/login.defs
they can always do a chmod 777 afterwards.

you generally want 002 so that installing programs works for everyone on the system,

you can do 007 which results in -rwxrwx--- preventing total world access, a warm fuzzy feeling but can be problematic in some cases if you have a lot of different groups defined.

you can do 027 to give a -rwx-r-x--- which can make some sense preventing world access and default group write access in order to protect data; requires increased admin involvement and remembering this because it will be problematic when installing programs or managing data folders when there is more than just a single users group. This is more for a system with many non-savvy linux users who are irresponsible with data, and you need to manage things for them... but remember they can always change the umask or chmod stuff they create.

if u look up disa stig, v-71955 and v72049, you can see their viewpoint of Failure to restrict system access to authenticated users negatively impacts operating system security

simply powering on your computer negatively impacts security... :roll:

horror story is not running umask 002 or worse than 007 that u install software and it does not work and you don't know why... software vendor will say not our fault, IT people managing mess will say not their fault.

There are other & better ways to manage data security; umask should not be used to do it. Using umask to do that is like using a big hammer...

Post Reply

Return to “CentOS 7 - Security Support”