Whether attending conferences or reading blogs, I often hear several misconceptions about sudo. Most of these misconceptions focus on security, flexibility, and central management. In this article, I will debunk some of these myths.
Many misconceptions likely arise because users know only the basic functionality of sudo. The sudoers file, by default, has only two rules: The root user, and members of the administrative wheel group, can do practically anything using sudo. There are barely any limits, and optional features are not enabled at all. Even this setup is better than sharing the root password, as you can usually follow who did what on your systems using the logs. However, learning some of the lesser-known old and new features gives you much more control and visibility on your systems.
If you only know how to give access in sudo to a specific command for a specific user or group, I would recommend reading some of my earlier articles on sudo:
As these article titles suggest, many beneficial possibilities have been available for over a decade without users noticing or using them, and sudo is still continuously developed. My responses to these common misconceptions may teach you about some new features!
Sudo configuration is stored locally, making it vulnerable
Yes, by default, configuration is stored locally. If you give users root shell or editor access, they can modify the sudoers file. On a single host, there is nothing you can do about it. Once you have multiple hosts, however, there are many ways to solve this problem.
All major configuration management platforms, including Ansible, have support to maintain the sudoers file. Even if the actual configuration is a local file, it is maintained from a central location. Any local changes can be detected, reported, and changed back automatically to the centrally managed version.
Another possibility is using LDAP (lightweight directory access protocol) to store sudo's configuration. It has quite a few limitations—for example, you cannot use aliases—but using LDAP means that the configuration is stored in a central directory, any change is effective immediately, and the local user cannot modify the settings.
Using LDAP for central configuration is difficult
If you have just a couple of freshly installed hosts, getting started with LDAP to store the sudo configuration can be difficult. However, most organizations, even with just a few hosts, already have LDAP or Active Directory (AD) running and personnel who know how to configure and maintain these directory services. Adding sudo support to an already existing directory service is not prohibitively difficult. It is even possible to have both local sudoers and LDAP sudoers, and to specify the order of evaluation, for example, LDAP first, then local, or local first, then LDAP.
Maintaining a sudoers file on multiple hosts is error prone and a compliance problem
Yes, this is right, as long as you edit individual sudoers files by hand. However, as suggested in my response to the previous myth, even with a very low host count, most organizations introduce some kind of directory services, such as LDAP or AD, and configuration management. You can use a directory service to store the sudo configuration centrally, or you can use Ansible and other configuration management applications to maintain the sudoers files on your hosts from a central configuration repository.
The sudo codebase is too large
Yes, it is large. Some even call it a Death Star and say that a large codebase also means that it is insecure. There are smaller software projects; however, those implement only a very basic subset of sudo functionality. Using those, you lose a lot of visibility into what is happening on your systems (just think about session recording). Commercial sudo replacements might implement many sudo features. However, sudo is open source and one of the most analyzed open source codes. Commercial codebases are even larger—and not analyzed by third parties.
Shell access visibility is tricky
Using just the default settings, shell or editor access makes it hard to see what's happening inside a shell session. However, session recordings have been able to make visible what happened inside a shell session for well over a decade. Version 1.9.0 of sudo introduced a central collection of session recordings, so they could not be deleted or modified by the local user. Version 1.9.8 also includes subcommand logging. You can use the logs to check any commands executed in a sudo session and only watch recordings when necessary (for example, if a user starts Midnight Commander). Watching session recordings is tedious and can be very time consuming—some people even have three-day-long sudo sessions—so reviewing logs whenever possible is definitely preferable.
You can't use two-factor authentication in sudo
That is right: There is no out-of-the-box two-factor authentication (2FA) in sudo. However, you can implement 2FA using Linux PAM. Or, if you prefer, you can do it inside sudo. Sudo has a modular architecture and thus can be extended. Version 1.9 of sudo introduced the approval plugin API (application programming interface), making it possible to have additional restrictions before executing a command. You can code your approval plugin in either C or Python and implement 2FA yourself.
Sudo logs do not improve security
If you collect log messages only locally and you do not check them at all, then log messages do not improve security. However, even syslogd, the original syslog implementation from more than three decades ago, supported central log collection. Removing sudo logs from a remote host or a cloud service is not as easy as modifying local logs.
There is also built-in support for central logging in sudo. Using sudo_logsrvd you can collect not only session recordings but event logs as well. In the end, sudo_logsrvd can forward events to syslog (default) or maintain its own log files.
Any questions?
I hope my article helped to resolve some of the myths surrounding sudo. If you have any sudo questions, do not hesitate to reach out to the sudo users mailing list.
Comments are closed.