Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

I've been skimming through the NSA suggestions for hardening Mac OS X and Linux and noticed this little tidbit of info:

Setuid programs run with the privileges of the file's owner (which is often root), no matter which user executes them. Bugs in these programs can allow privilege escalation attacks. To find setuid and setgid programs, use the commands:

find / -perm -04000 -ls
find / -perm -02000 -ls

After identifying setuid and setgid binaries, disable setuid and setgid bits (using chmod ug-s programname) on those that are not needed for system or mission operations.

My question is, how does one identify which apps can have their setuid/setgid bits disabled? For example, I'm assuming some apps like su, sudo, and login must have setuid. On the other hand, something like write probably does not need setuid. Is there a good way to find out whether an app really needs it?

share|improve this question

1 Answer 1

up vote 1 down vote accepted

That's a good question.

Usually, applications that need the setuid and setgid bit are applications need to perform administration tasks by non-root users.

Take for example the passwd program. It is used for changing one's password. The passwords are store in the /etc/shadow file, that's only readable by root, hence the use of the setuid bit.

Generally, in popular Linux distros, those applications are safe to use, cause they're all tested and bug free.

I don't know how you can find out whether an application needs those bits on or not, but you can install an applicatio like snort or AIDE that checks the integrity of files and can alert you when some file has been changed - particularly those with setuid and setgid bits on.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.