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