Linux.com Article DB: Linux Security Advice: suid Programs

This is not going to be another article on inetd.conf, or even firewalling your Linux box. Those are both great security measures, but they've been done to death. Instead, I'm going to talk about protecting your box from your own users.

Here's the scenario. You've got a Linux server, and of course you've: gotten rid of unneeded services, you only installed the packages you needed, and you've patched them to the most current version. For whatever reason, you have users on your system, with shell access. But you want to make sure they can't do anything more than what you allow them to.

First, make a list of all the things every user needs access to: programs, services, and directories. Now sort out groups of users who need more access. For example, programmers will need access to the GNU debugger, gdb, but no one else really should. Once you have your list of general user requirements, and then specific group requirements, you can start restricting access for each group, and adding users to those groups. Each system will have different needs along these lines, but you see the general idea.

suid

Now, it would be good idea to restrict access to things like gdb, some networking tools, and so forth, since they can be used to crack system security and similar things. But the first thing you should get rid of is anything that is suid root. Set User ID, or suid, is a special flag that means not only is the program executable, but it also runs with the owner's permissions and privileges, meaning that a program that is suid root runs always as if root had run it. sgid or Set Group ID, is the same concept, only for groups, rather than owners.

Some things, like passwd, must be suid root to function, but anything that doesn't absolutely, positively need to be root, change it's group, make it sgid, remove the suid flag, and have a special group own it, that has just the permissions needed and no more. Suid programs are sometimes vulnerable to buffer overflows, or are vulnerable to attack in the way the program is written, so that you can trick it into running another program as root.

To find suid programs on your system, try this :

[jrmorris@lycurgus]$ find / -perm -4000 2>/dev/null

That will return a list of suid programs on your system. For sgid programs, try :

[jrmorris@lycurgus]$ find / -perm -2000 2>/dev/null

The Tricky Part

The tricky part in all this is determining what the program in question actually needs access to. The way I usually do that, if I don't already know, is by setting it to run normally, by chmod 755 , and then seeing what error messages pop up when it runs. Then, make it sgid and give its group read access to the things it complained about. If that doesn't work give the group execute access, then finally, write access. Sometimes the program isn't nice and won't give good error messages, so you have to infer from what it does what it is likely to need. Finally, you may find you need to have two different groups accessing the same files; do so by making one group the member of the other, and having that one be the file's group.

John R. Morris jrmorris@nerdality.com Sr. Unix System Administrator & Penguin devotee, Nerdality Consulting.

Originally Published: Wednesday, 16 May 2001	Author: John R. Morris
Published to: enchance_articles_security/Basic Security Articles	Page: 1/1 - [Printable]
Linux Security Advice: suid Programs Today senior administrator John Morris reminds us of the dangers of `suid` programs, and gives us some advice on how to identify and deal with them in this Linux.com security update.

	Page 1 of 1
This is not going to be another article on `inetd.conf`, or even firewalling your Linux box. Those are both great security measures, but they've been done to death. Instead, I'm going to talk about protecting your box from your own users. Here's the scenario. You've got a Linux server, and of course you've: gotten rid of unneeded services, you only installed the packages you needed, and you've patched them to the most current version. For whatever reason, you have users on your system, with shell access. But you want to make sure they can't do anything more than what you allow them to. First, make a list of all the things every user needs access to: programs, services, and directories. Now sort out groups of users who need more access. For example, programmers will need access to the GNU debugger, gdb, but no one else really should. Once you have your list of general user requirements, and then specific group requirements, you can start restricting access for each group, and adding users to those groups. Each system will have different needs along these lines, but you see the general idea. suid Now, it would be good idea to restrict access to things like gdb, some networking tools, and so forth, since they can be used to crack system security and similar things. But the first thing you should get rid of is anything that is `suid` root. Set User ID, or `suid`, is a special flag that means not only is the program executable, but it also runs with the owner's permissions and privileges, meaning that a program that is `suid` root runs always as if root had run it. `sgid` or Set Group ID, is the same concept, only for groups, rather than owners. Some things, like `passwd`, must be `suid` root to function, but anything that doesn't absolutely, positively need to be root, change it's group, make it `sgid`, remove the `suid` flag, and have a special group own it, that has just the permissions needed and no more. `Suid` programs are sometimes vulnerable to buffer overflows, or are vulnerable to attack in the way the program is written, so that you can trick it into running another program as root. To find `suid` programs on your system, try this : `[jrmorris@lycurgus]$ find / -perm -4000 2>/dev/null` That will return a list of `suid` programs on your system. For `sgid` programs, try : `[jrmorris@lycurgus]$ find / -perm -2000 2>/dev/null` The Tricky Part The tricky part in all this is determining what the program in question actually needs access to. The way I usually do that, if I don't already know, is by setting it to run normally, by `chmod 755` , and then seeing what error messages pop up when it runs. Then, make it `sgid` and give its group read access to the things it complained about. If that doesn't work give the group execute access, then finally, write access. Sometimes the program isn't nice and won't give good error messages, so you have to infer from what it does what it is likely to need. Finally, you may find you need to have two different groups accessing the same files; do so by making one group the member of the other, and having that one be the file's group. John R. Morris jrmorris@nerdality.com Sr. Unix System Administrator & Penguin devotee, Nerdality Consulting.
	Page 1 of 1