The declining security of Linux (and sudo considered harmful)

Naive approaches to computer security have long been a thorn in my side, starting with the long lasting Windows assumption of a single user and user account on a system. (Originally explicit in that no second user account or user control was available; in the last ten-or-so-years in the form that the standard case is one user and one user only—who if at all possible should only ever work with one account.)

Unfortunately, Linux has also taken a turn for the worse over the years, often taken extremely naive approaches, prioritizing the convenience of the inexperienced user over security*, and opening holes that even a highly proficient user is often unaware of—and with more and more holes as time goes by.

*With the dual effect that those who want security have to put in a load of work (and likely still fail) and that many users are not aware of how poor their security is. Notably, the naive users might be pleased about the convenience—but they too are victims of the poor security. I would even argue that because they are naive, there is a greater obligation to protect them through implementing strong default security.

A prime example is the default file permissions (umask), which on most modern systems are set so that anyone can read the files of everyone else… This is so obviously wrong and idiotic that whoever is responsible should be taken out and shot. The obvious correct default behavior, and what matches the reasonable intent on almost all systems, are permissions where either only the owner is allowed to read a file or only the owner and the members of the files “group”*. One of the first things I do with a new installation is to restrict the default file permissions to owner only—if something else is needed for a specific file, I override the default.

*The standard file permissions on Unix-like systems divide the world into the owner, the group, and everyone else. By assigning users to a group, they can be given different access to certain files than “everyone else”, without being the owner.

This misconfiguration is particularly dangerous because it is unexpected, it is often only discovered when it is (potentially) to late, and it requires an over-average amount of knowledge to correct*.

*It is not enough to simply change the default setting: Each and every file that has already been created with that setting must have its individual setting corrected.

Another particularly annoying and dangerous problem is demonstrated by utterly conceptually flawed tools like sudo, pkexec, and polkit: Much like the execution controls in Windows, they assume that a user has a varying amount of rights to do things depending on how he does them. (E.g. through calling a command with or without sudo, or through giving or not giving a password to polkit.) While these tools are intended to increase security, they instead open up ridiculous security holes, and increase the likelihood both of users being given rights that the admins never intended them to have and of hostiles being able to achieve “privilege escalation”*.

*Roughly, an attacker starting with a certain set of rights that do not pose a danger and tricking the system into giving him more rights until he does pose a danger. This is a central part of cracking a computer system.

Consider sudo: The intention of sudo is that when a user executes the command X as “sudo X” (instead of just “X”), it is as if root (the main admin user) executed the same command. Now, what commands are allowed to “sudo” for a certain user is configurable, but this configuration can be a bitch. Take something as harmless as an editor: If the user can “sudo” the editor, he can now change system files, manipulate the password storage, read documents that should be secret, … The system is effectively an open book that a skilled cracker can exploit and infiltrate as he sees fit. OK, so we do not allow editors (and a number of more obvious things like command shells, commands to delete files, and the like). Now what about all the other applications that are not editors but still have the ability to execute editors or have the ability to even just save a file? What about those that can execute commands (e.g. through a “shell escape”—a very common mechanism on Unix-like systems)? They too must be ruled out. Etc. But here is the real devilry: How do we find out what commands have what abilities? This is a virtually impossible task, with many nasty surprises—e.g. that the standard pager (“less”; seemingly only intended to view files) has the ability to launch an editor… The only chance is to reduce the “sudoable” commands to an absolute minimum, carefully verify that minimum, and (more likely than not) conclude that the users now do not receive the convenience that sudo was intended to give them.

The task of configuring sudo is made the harder because most Linux distributions appear to work on the assumption that any system is a single user system (as with Windows above)—and cram down whatever gives the user convenience in the corresponding configuration. Looking at the configuration file /etc/sudoers on my current system*, I find e.g.

*No worries: While the configuration file is still there, the actual sudo program has been removed.

# Allow members of group sudo to execute any command

%sudo ALL=(ALL:ALL) ALL

The comment line says it all.

Now, a good admin would not assigns the group “sudo” to just anyone and would use far more granular settings to give individual users what they need. However, not all admins* are good and this approach practically invites the admin to be lazy and assign rights carelessly. To boot, this makes it ease for the Linux distribution to screw up, because the consequences of a change become hard to predict, e.g. when default group assignments or default configuration entries are altered. In one horrendous case I heard of some months ago, the default configuration actually gave everyone, irrespective of group, the right to “sudo” anything, resulting in a system with no actual security anymore…

*Note that the admin is often quite, quite poor as an admin: Admins are not just found in big enterprises—the family member who takes care of the family’s computers is also an admin.

Others do truly stupid things, like https://help.ubuntu.com/community/Sudoers which gives an example of how to add an editor (!) to the configuration—and this in a section titled “Common Tasks”…

myuser ALL = (root) NOPASSWD:NOEXEC: /usr/bin/vim

This example lets the user “myuser” run as root the “vim” binary without a password, and without letting vim shell out (the :shell command).

Well, preventing “shell out” (more properly “shell escape”, one of the issues I mention above) is good, but obviously the idiot who wrote this has failed to understand that an editor is lethally dangerous too (cf. above). For instance, “sudo vim /etc/shadow” gives a malicious user the possibility to change the root password, after which he can trivially gain a root shell—without needing a “shell out”.

In contrast, the earlier approach was very sound: Either a user account had the right to do something or it did not—end of story. Usually, “did not” applied, when not dealing with the users own files. When more rights were needed to do a task the physical user had to log in with a new user account with more rights in the relevant area (and typically less in other areas!)—if he was trusted with such an account*. Yes, sudo can be more convenient, but that convenience is bought with a horrendous drop in security.

*If he was not trusted, then he correctly had no opportunity to do whatever he wanted to do.

The one saving grace of sudo is that it makes live a little safer for those who would otherwise take even greater risks in the name of convenience, through giving themselves dangerous rights all the time. This, however, is not a valid reason to make life that much less secure for the users who actually try to be secure and know how to handle themselves. This is like noting that condoms reduce pleasure and replacing condoms with some other mechanism which gives more pleasure—but does so at the price of not actually preventing pregnancy and disease transmission…

As a rule of thumb: If someone recommends that you use sudo, discount anything he says on security issues. This tool is simply one of the worst security ideas in the history of Linux.

I have seen some truly absurd cases, e.g. one nitwit who adamantly insisted that logging in as root on a terminal was very dangerous, but still threw sudos around willy-nilly. (While logging in as root is never entirely without danger, a terminal is the least dangerous place to do so, seeing that this reduces the risk of a snooper catching the password, removes the temptation of starting various GUI programs, and drastically reduces the risk of forgetting that one is using the root account and mistakenly doing something stupid.)

Excursion for the pros:

Those who know a little more about Unix security might see a major advantage of sudo in the reduced need for suid-ing programs. This might or might not have been an advantage at some point of time, but I have worked for years without using sudo and I have never needed to change anything in this regard. I conclude that what should work works, be it through appropriate group settings, daemons, or suid programs that are there irrespective of the presence of sudo. In addition, I am not convinced that suid programs, the potential dangers notwithstanding, are a greater evil than sudo, at least not after considering the relative likelihood of an admin doing some stupid—it is not just a question of what approach is the safer technically, but also of what approach gives us the better protection from human errors.

Advertisement