Mistakes to avoid when using privilege elevation
Centrify DirectAuthorize can be a powerful tool to enable granular privilege elevation for users on a UNIX/Linux system. But like is homologue sudo, it can be used badly and lead to not so secure situation. When using dzdo to hardening security of your systems, you need first to think about the known pitfalls about granting UNIX Commands as root so you avoid users being able to become root on a system when it is clearly not what you aim in the first place.
Let’s see few common mistakes that can be avoided by looking at a very simple scenario. Pretend a moment we have a user named Cathy. She’s part of the Linux Support team, and then can logon on Linux servers as a normal user where she may need to look into system logs for diagnose purpose. Of course files under /var/log are not readable for other users than root (if this is the case then don’t read further this article before to have fix permissions on your file system!). For obvious reasons, you don’t want to have Cathy to logon as root on these systems just for the sake of being able to read logs. Then granting her privilege commands to do this seems a good idea.
In our scenario, Cathy has access to a Linux server on which she can run the following command using dzdo:
This command seems perfectly fine. But in reality, Cathy is able to become root or access much more files than this command seems to define.
Command execution (and shell escape)
One things that need to be understood is that several UNIX Commands allow other commands to be run from them. This is the case for vi, more, less, man, etc.
When running such command with root privileges, then the nested executed command is run as root. Innocently giving commands like more not knowing about nested execution, is effectively allowing a “bad guy” to become root on a system.
Let’s illustrate this with Cathy.
Cathy use dzdo to open /var/log/messages using the more command she is allowed to use:
She has access to the file as root (as configured when using dzdo), so can access the content of the file normally not readable for her:
Then, if Cathy hit the “!” key, she is able to execute any command as root, like /bin/bash for example. Cathy has now full root access to the system:
Usage of wildcards when specifying UNIX Commands with DirectAuthorize (or in a Sudoers file) can be perceived as a nice and smart way to configure several commands in one. If Cathy probably need to only have access to /var/log/secure and /var/log/messages (or other relevant files depending of the OS) to be able to diagnose a system, if you want to allow more it will be tempting to use a wildcard rather then define all the possible files.
This unfortunately is rarely understood as a mistake that allow anyone granted a command using wildcard in a path to execute this command against ANY file on the system.
Let’s first talk about a nasty feature available with editors such vi, more and less. The ability to open a chain of files in one command.
Cathy use dzdo to open /var/log/messages using the more command she is allowed to use, but also open /etc/shadow at the same time. Thanks to the wildcard in the command, she is allowed to do this:
She has access to the file as root (as configured when using dzdo), so can access the content of the file normally not readable for her. Also the header of the more command kindly indicate that she is currently viewing the content of the /var/log/messages file:
Then, if Cathy hit successively the “:” and “n” key, she is able to edit the next file in the chain which is /etc/shadow. Because more is running in root context, Cathy has full access to the file and the password hashes of all local users on this system:
Another wildcard exploit is to use a relative path in the command, which is also allowed as long as file permissions allow to go up in the file system tree (which is generally the case).
Cathy use dzdo to open /etc/shadow using a relative path to the file and using /var/log/ as a starting point. Thanks to the wildcard in the command, she is allowed to do this:
Because more is running in root context, Cathy has full access to the file and the password hashes of all local users on this system:
This could be considered meaningless, but understand that the file permissions on /etc/shadow are made that only root can read it for a simple reason: knowing the hash of a user is knowing his password.
There is Rainbow tables available on the Internet that can help cracking passwords in seconds. Even without a Rainbow table, with enough time and patience a brute force crack is not a big effort considering how computers are powerful now days.
DirectAuthorize or sudo are just tools, there is nothing preventing you to badly using them except a good understanding of the commands you want to elevate and knowledge of the caveats in the context of privilege elevation.
There is few rules that can be a good start for a more secure usage of dzdo or sudo and help hardening the system efficiently.
A first level of security is to prevent the nested execution for all commands that would allow to execute arbitrary commands or escape a command as root. This can be done using the NOEXEC flag in a Sudoers file, and by unchecking the “Allow nested execution” on the UNIX Command definition when using DirectAuthorize:
Now when Cathy will try to execute a command from more, she will be denied to do so as the command will have ben run as root with no nested execution allowed in this context:
A second things is to wisely define the commands and their parameters so a user is not able to exploit things such wildcards or program features allowing to access more files than expected or use a command for another usage than expected.
If Cathy would need only access to secure and messages logs, instead of using wildcards it is recommended to define each file in a separate command definition:
DirectAuthorize allow usage of regular expression for command definition, which is far more powerful than GLOB expression supported by Sudoer. As example, a regular expression can be used to allow both files in a single command definition. The regular expression below will match the word “secure” or “messages” after the expression “more /var/log/”:
Talking about regular expressions. You can then go crazy a bit and allow any files or file path under /var/log but disallow usage of a space, which will prevent user to open chain of files with the more command. The regular expression below will match any word after the expression “more /var/log/” but will not match use of space:
This will prevent chain execution:
Adding another command with the regular expression below will deny a match of any word after the expression “more /var/log/” that contains “..”
This will prevent usage of relative path in the command argument:
Finally, this could be combined in a smarter way by letting the command defined with a wildcard as it is, but adding a deny rule using regular expression that avoid wildcard exploit. Then the commands for using more would look like this:
Unfortunately, Sudoers does not support regular expressions, and setting rules using wildcards in a secure way is a challenge.
When granting privileged commands to users, it is very important to understand how the command works and what arguments or features maybe be exploited by a user when the command run in root context. Being able to understand this can decide of how to setup the command or eventually not even allow it if judged too risky.
In any case, if hardening a system is a problem for you, DirectAuthorize support of regular expression to define commands can be a very good way to move from sudo and obtain a significant gain in security in addition to the nice fact of managing your privileges from a central point of management: Active Directory.