While running Linux as a server, one guiding principle that has served me well is to continually ask, "what am I trying to achieve?" Does it make sense for a web server to have the printing subsystem installed? Should a system with no console have gpm installed? Usually, extra software packages just take up unnecessary disk space, but in the case of setuid or setgid binaries, the situation could be far worse.
While distribution maintainers work very hard to ensure that all known exploits for setuid and setgid binaries have been removed, it seems that a few new unexpected exploits come out every month or two. Especially if your server has more shell users than yourself, you should regularly audit the setuid and setgid binaries on your system. Chances are you'll be surprised at just how many you'll find.
Here's one command for finding all of the files with a setuid or setgid bit set:
[root@host]# find / -perm +6000 -type f -exec ls -ld {} \; > setuid.txt &
This will create a file called setuid.txt that contains the details of all of the matching files present on your system. It is a very good idea to look through this list, and remove the s bits of any tools that you don't use.
Let's look through what we might find on a typical system:
-rws--x--x 1 root bin 35248 May 30 2001 /usr/bin/at -rws--x--x 1 root bin 10592 May 30 2001 /usr/bin/crontab
Not much surprise here. at and crontab need root privileges in order to change to the user that requested the at job or cron job. If you're paranoid, and you don't use these facilities, then you could remove the setuid bits with:
[root@host]# chmod a-s /usr/bin/{at,crontab}
Generally speaking, it's a bad idea to disable cron (as so many systems depend on timed job execution). But when was the last time you used at? Do your users even know what it's for? Personally, I find at a nice shortcut to setting up a full-blown cron job, and wouldn't like to part with it. But if there is no call for it on your particular system, you should consider defanging it. With the setuid bit removed, the commands will no longer be available to regular users but will still work fine as root.
-rws--x--x 1 root bin 11244 Apr 15 2001 /usr/bin/disable-paste
This is part of the gpm package (a mouse driver for the Linux console). Do you have a mouse attached to the console of this machine? Do you use it in text mode? If not, then why leave a setuid root binary in place that will never even be called?
-r-s--s--x 1 root lp 14632 Jun 18 2001 /usr/bin/lpq -r-s--s--x 1 root lp 15788 Jun 18 2001 /usr/bin/lpr -r-s--s--x 1 root lp 15456 Jun 18 2001 /usr/bin/lprm -r-xr-s--x 1 root lp 23772 Jun 18 2001 /usr/sbin/lpc
These are all part of the printing subsystem. Does this machine actually use lp to print?
-rws--x--x 1 root bin 33760 Jun 18 2000 /usr/bin/chage -rws--x--x 1 root bin 29572 Jun 18 2000 /usr/bin/chfn -rws--x--x 1 root bin 27188 Jun 18 2000 /usr/bin/chsh -rws--x--x 1 root bin 35620 Jun 18 2000 /usr/bin/passwd
These are all necessary for users to be able to set their passwords, shell, and finger information. Does your site use finger information at all? If, like most sites, you have a roster somewhere else (probably on the web) that isn't kept in sync with user's GECOS field, then this information is generally useless (except for the user's "real" name, which is still used in some email clients). Do you really need to allow users to change this information on their own, without admin intervention?
-r-xr-sr-x 1 root tty 9768 Jun 21 2001 /usr/bin/wall -r-xr-sr-x 1 root tty 8504 Jun 21 2001 /usr/bin/write
Both wall and write need to be setgid tty to write to other user's terminals. This is generally a safe operation, but can be abused by miscreants who like to write bad data (or lots of bad data) to other user's terminals. If you don't need to provide this functionality to other users, why not disable the setgid bit? If you do, root will still be able to send walls and writes (for example, when a message is sent by shutdown when rebooting the system).
-rwsr-xr-x 1 root bin 14204 Jun 3 2001 /usr/bin/rcp -rwsr-xr-x 1 root bin 10524 Jun 3 2001 /usr/bin/rlogin -r-sr-xr-x 1 root bin 7956 Jun 3 2001 /usr/bin/rsh
The r* commands are left from an age (perhaps not so long ago), before the days of ssh. Do you need to provide the r commands to your users? Is there anything that ssh and scp can't do that you absolutely need rsh and rcp for? More than likely, once you've worked with ssh for a while, you'll never miss the r commands, and can safely remove the potential ticking time bomb of a disused setuid rsh installation.
-r-sr-xr-x 1 root bin 10200 Jun 3 2001 /usr/bin/traceroute -r-sr-xr-x 1 root bin 15004 Jun 3 2001 /bin/ping
The traceroute and ping commands need the setuid root bit to be able to create ICMP packets. If you want your users to be able to run these network diagnostic tools, then they'll need to be setuid root. Otherwise, remove setuid and then only root will be able to run ping and traceroute.
-r-sr-sr-- 1 uucp uucp 83344 Feb 10 2001 /usr/bin/uucp -r-sr-sr-- 1 uucp uucp 36172 Feb 10 2001 /usr/bin/uuname -r-sr-sr-- 1 uucp uucp 93532 Feb 10 2001 /usr/bin/uustat -r-sr-sr-- 1 uucp uucp 85348 Feb 10 2001 /usr/bin/uux -r-sr-sr-- 1 uucp uucp 65492 Feb 10 2001 /usr/lib/uucp/uuchk -r-sr-sr-- 1 uucp uucp 213832 Feb 10 2001 /usr/lib/uucp/uucico -r-sr-sr-- 1 uucp uucp 70748 Feb 10 2001 /usr/lib/uucp/uuconv -r-sr-sr-- 1 uucp uucp 315 Nov 22 1995 /usr/lib/uucp/uusched -r-sr-sr-- 1 uucp uucp 95420 Feb 10 2001 /usr/lib/uucp/uuxqt
When was the last time you connected to another machine with UUCP? Have you ever set up the UUCP system? I have been a network admin for ten years, and in that time, I have never come across a live UUCP installation. That's not to say that UUCP isn't useful, just that in these days of permanently connected TCP/IP networks, UUCP is becoming extremely uncommon. If you're not using UUCP, then leaving setuid and setgid binaries online to support it doesn't make much sense.
Do any of the binaries in the examples above have potential root (or other privilege elevation) exploits? I have no idea. But I do know that by removing unnecessary privileges, I minimize my exposure to the possibility that an exploit might be run on this system if one is discovered.
I have tried to present this hack as a process, not as a solution. This list is certainly by no means definitive. As you build a server, always keep in mind what the intended use is, and build the system accordingly. Whenever possible, remove privileges (or even entire packages) that provide functionality that you simply don't need. Consult the manpage if you ever wonder about what a particular binary is supposed to be doing, and why it is installed setuid (and when the manpage fails you, remember to use the source).
