Bugzilla – Bug 720
Files inside folder /etc/sudoers.d/ can break a system; doc is not clear
Last modified: 2015-09-21 15:44:15 MDT
My report is about what I have learning after reading a blog post and its comments about a problem someone had with the /etc/sudoers.d/ and his Ubuntu. But the problem affects at least all other Debian based distros I know, and even other OSes or platform too, as one comment made in that blog entry showed. There are things I want to be changed, since I could have this problem too, naturally (and I used Debian based distros, as most as I can, or Debian itself). From here on, all the files I mention are relative to /etc/sudoers.d/ directory. The README file contains: ==================== # Note that there must be at least one file in the sudoers.d # directory (this one will do), and all files in this directory # should be mode 0440. ==================== This is a absurdly wrong statement that will lead to broken systems, given some contexts (that are common, nonetheless). This line should be changed to more informative and clear statements of the consequences of this suggestion¹. For example: ==================== # Note that there must be at least one file in the sudoers.d # directory. This file only, and containing just comments is enough. # All files in this directory must have mode 0440. This restriction # must NEVER be disrespected, or the sudo command cannot be started # without serious security implications existing. # # WARNING: if sudo is the only way to get administrator access # on your machine, be very careful when editing or creating files # in this directory! You can lose it. ==================== Another details that may be changed is the actual need of the permission restriction. I understand why it is needed. But why 044 instead of 444? And if the system only uses sudo to gain administrative access, there must be a path for a step back of a single state change (like the creation of a file with wrong permissions, as the blog told, and probably as I would have this problem). There are some data that may allow a better decision of what to do when a wrong situation is found: file creation date; file change date; the previous valid state of the folder, maybe even including its contents. The folder contents will usually be just text files, and any tar.bz2 present there solves it (with restrict permission restrictions, of course, or we would create a security hole that we're trying to just improve). End notes: ¹ The word "should" implies in a suggestion. This is a common and usually correct way to interpret text and documentation, as you may have seen before. I have chosen 1.6 version because it's the earlier version I could see that may be affected by this problem. And it affect the current version, since the blog showed a comment for Ubuntu 14.04 LTS with the issue. I could not choose more than one component for this report, so I chose the most general as a way to guarantee all proposed changes are considered by different people, if this is needed.
The blog post I mention in the report, is given in the URL field. It is: http://www.peppertop.com/blog/?p=1015 But I have tried to make all points clear enough in the report itself. More details can be found on the blog, if needed or if anyone wants to read there.
That README file is part of the Debian sudo package, it is not in the sudo distribution. I suggest you file a bug with Debian if you feel the contents are insufficient.