Enablement Security Policies with Sudo

Policies in Linux

You get many types of security policies that allow or prevent users in a multiuser environment to perform a certain task. You get policies that allow a specific task, and you get policies that disallow a task where it would otherwise be allowed, and policies that control the frequency or limit that amount of times a task can be performed, and so on.

Linux doesn’t have a single system or architecture for such policies. Software usually implement these themselves and provide a way to manage them if the administrator wants to enable them. Though, an enormous amount of control can be exercised with process ownership and file permissions or ACLs alone.

However, the root user (administrator user on Unix systems) on Linux has total control. When you have a root shell there is no file you can’t edit, or no process you can’t control. With ultra high security requirements this can be a problem. SELinux is a system which implements policies in a different way where you can secure your system beyond what is available by default. For more information on SELinux, see SELinux on WikiPedia.

Creating Policies with sudo

Let me explain with a hypothetical example. Assume you wanted to give a specific group of users the ability to clear a certain process’ log file.

To do this the file itself needs to be emptied and a USR1 signal sent to the process to have it reopen the file. The process runs as user and group foo, so the logged in users will not be allowed to send a signal to it. The log file is also owned by the same foo user and group, so they won’t be allowed to write to it, and thus can’t empty it either.

To give them access to this, you can create a group named logflushers which will control access through membership. Then create a script that performs the 2 necessary tasks. Assuming the script is named /usr/bin/flushfoolog, you can add the following line to the /etc/sudoers file to enable the members of the logflushers group to execute the command as the foo user:

%logflushers ALL=(foo) NOPASSWD: /tmp/notouch

With this in place any of logflushers group’s members can flush the log by running:

sudo -u foo flushfoolog

If the user is not part of the logflushers group and they try to run this, they’ll get an error like the following:

Sorry, user quintin is not allowed to execute '/usr/bin/flushfoolog' as
foo on localhost.

Simplifying the Command

The command to flush the foo log seems a bit redundant. You can simplify it by adding the following to the top of the /usr/bin/flushfoolog bash script. If it’s not a bash script you just need to implement the same logic in whatever language it is.

targetuser=foo
if [ $(id -u) -ne $(id -u $targetuser) ]
then
  sudo -u $targetuser "$0"
  exit $?
fi

What this does is check if the script is being run as the foo user. If it’s not, then it will execute the same command as the foo user, using sudo. If a user isn’t granted permission to run this command via sudo, (they’re not in the logflushers group) then they’ll get the error saying they’re not allowed to run this command as the foo user.

Conclusion

Sudo makes it very easy to control or grant access to commands to certain users. If combined with scripts access control can be made finer performing programmatic tasks or access control inside the script.

So Why Love Linux? Because it’s so simple to implement flexible access control when combining sudo and scripting.