It is common for system administrators to be thought of as strict gatekeepers, not allowing access to anybody.
In my experience nobody bats an eye when you’re unable to use the Administrator account on a company laptop, but having to run
sudo without simply switching to root on a Linux server is absurd.
The hardening and security of Linux servers is very important, yet so many people and companies fail to restrict access correctly. I have always been an advocate of enforcing the correct use of sudo, specifying commands instead of allowing full root access. Command exclusion is equally important, and in my opinion often overlooked. A good sudoers configuration will exclude users from running commands that could potentially allow them to get a root shell, this includes excluding all shells, management tools such as
chmod, and even commands like
tar, which can easily be used for privilege escalation.
vi poses an issue when users do need to edit files on the system. Thankfully the contributors to
sudo came up with a solution, the
-e option or
sudoedit option allows a user to edit files by making a temporary copy owned by the user. To give an example, lets say we have a user that requires permission to edit the Apache config file. They can be granted access in /etc/sudoers, or my preferred method is to put a file into /etc/sudoers.d/. The line would look like this
bob ALL=(ALL) sudoedit /etc/httpd/conf/httpd.conf
The user can then edit the file in one of two ways
sudo -e /etc/httpd/conf/httpd.conf sudoedit /etc/httpd/conf/httpd.conf
This creates a copy of the file in /var/tmp, such as
"/var/tmp/httpdXXJkszaG.conf", which is owned by the user. Once the changes have been made the file can be saved and exited as normal.
Wildcards can also be used to specify whole directories or multiple files
bob ALL=(ALL) sudoedit /etc/httpd/conf/httpd.conf, sudoedit /etc/httpd/conf.d/*.conf
Recently I had a user who required access to read some of the system log files so they could debug an issue. As expected I didn’t want to grant them sudo permission, overkill for reading some files. Instead I opted to use the file access control list tool
setfacl. To grant a use read permissions to a file incant
sudo setfacl -m u:bob:r /var/log/messages
Group permissions can also be set with
sudo setfacl -m g:bob:r /var/log/messages
To view a file’s ACLs incant
sudo getfacl /var/log/messages
The output will look something like this
getfacl: Removing leading '/' from absolute path names # file: var/log/messages # owner: root # group: root user::rw- user:bob:r-- group::--- mask::r-- other::---k
Removing a user’s access once they no longer need it is done with the
setfacl -x u:bob /var/log/messages
The use of ACLs means you don’t need to modify the file or directories ownership but can still safely give users the permissions they require.
Be careful if setting ACLs on log files as the permissions will be lost when the logs are rotated. If you require persistence add the
setfacl line(s) to the relevant logrotate config file.
sudo should not be shied away from, but it should also not be used in an all or nothing manner. It may annoy your users but you will rest well at night knowing that you have control and no one can take that from you, something, something, gatekeeper.