Removing setuid option for security.

UNIX for Beginners Q & A UNIX for Dummies Questions & Answers
1

According to Security standards given in
https://www.stanford.edu/dept/as/ia/security/policies_standards/AS_standards/RH_linux_prod_sec_std_1.0.1.html

Being a production system i want to implement the same on our server.
but when i tried finding other files i got following output.

# ls -ltr `find / -user root -perm -4000 -print`
find: /proc/10558/task/10558/fd/4: No such file or directory
find: /proc/10558/fd/4: No such file or directory
-rwsr-xr-x 1 root root  43976 Jun  5  2007 /usr/bin/at
-rwsr-xr-x 1 root root   6240 Jun  6  2007 /usr/sbin/ccreds_validate
-rwsr-xr-x 1 root root  22984 Jun  6  2007 /usr/bin/passwd
-rwsr-xr-x 1 root root  40976 Jul 31  2008 /opt/oracle/usr/libexec/libvirt_proxy
-rwsr-x--- 1 root dbus  45148 Oct 31  2008 /lib/dbus-1/dbus-daemon-launch-helper
-rwsr-xr-x 1 root root  31244 Oct 31  2008 /bin/ping6
-rwsr-xr-x 1 root root  35864 Oct 31  2008 /bin/ping
-rwsr-xr-x 1 root root  19184 Nov  1  2008 /sbin/unix_chkpwd
-rwsr-xr-x 1 root root  12248 Nov  1  2008 /sbin/pam_timestamp_check
-rwsr-xr-x 1 root root  24588 Nov  1  2008 /usr/bin/newgrp
-rwsr-xr-x 1 root root  51512 Nov  1  2008 /usr/bin/gpasswd
-rwsr-xr-x 1 root root  46972 Nov  1  2008 /usr/bin/chage
-rws--x--x 1 root root  32780 Nov  1  2008 /usr/sbin/userhelper
-rwsr-sr-x 1 root root 315416 Nov  1  2008 /usr/bin/crontab
-rwsr-xr-x 1 root root 176572 Nov  6  2008 /usr/libexec/openssh/ssh-keysign
-rwsr-xr-x 1 root root  70776 Jan 21  2009 /sbin/mount.nfs4
-rwsr-xr-x 1 root root  70772 Jan 21  2009 /sbin/mount.nfs
-rwsr-xr-x 1 root root  70776 Jan 21  2009 /sbin/umount.nfs4
-rwsr-xr-x 1 root root  70776 Jan 21  2009 /sbin/umount.nfs
---s--x--x 2 root root 140712 Jan 22  2009 /usr/bin/sudoedit
---s--x--x 2 root root 140712 Jan 22  2009 /usr/bin/sudo
-rwsr-xr-x 1 root root  38936 Jan 22  2009 /bin/umount
-rwsr-xr-x 1 root root  58324 Jan 22  2009 /bin/mount
-rws--x--x 1 root root  19096 Jan 22  2009 /usr/bin/chsh
-rws--x--x 1 root root  17900 Jan 22  2009 /usr/bin/chfn
-rwsr-xr-x 1 root root  23960 Jan 22  2009 /bin/su
-rwsr-xr-x 1 root root 147631 Apr  8  2009 /usr/kerberos/bin/ksu
-rwsr-xr-x 1 root root   6820 Jun 28  2009 /usr/sbin/usernetctl
-rwsr-xr-x 1 root root  64908 Jul 15  2009 /usr/libexec/libvirt_proxy

Now i m confused over how to remove setuid options on these files? and more important will it impact on rest of the sytem?

2

Without knowing what apps are on your systems, I would hazard a guess: Yes, it will break a lot things. In general do not change permissions on objects in /usr/bin on the advice of a website somewhere. They are part of the system and the designers want them to be as they are. Not as an academic type at Stanford wants thewm to be in his little shop of horrors.

For example:
Everybody expects their scripts to be able to run ping. Because it uses a restricted TCP port number it requires setuid.

Disabling kerberos will break some networking apps.

As a counterexample
consider the at.deny, at.allow, cron.deny, cron.allow, /etc/sudoers files to control access to at, crontab, and sudo. Rather than changing permissions on system files.

Don't remove the setuid permissions.

3

There's some worryingly important things in there, like mount, ping, chage, crontab, and so forth. Just blindly removing the bits would probably be a disaster.

4

what would be better would to note down what is setuid and check it every month.
if new stuff show up as setuid then you need to ask questions.

5

rather than remove suid. just chmod o-rx. I would have no issue with removing world execute on the following files. don't forget to review setgid binaries. They may also want to revise their STIG -- it's three years old! I also love the statement at the top of the page "Internal Distribution Only Not for Public Dissemination!" yet the damn page is available to the world. go figure.... *sigh*

/usr/bin/at
/usr/bin/passwd
/bin/ping6
/bin/ping
/usr/bin/gpasswd
/usr/bin/chage
/usr/sbin/userhelper
/usr/bin/crontab
/sbin/mount.nfs4
/sbin/mount.nfs
/sbin/umount.nfs4
/sbin/umount.nfs
/usr/bin/chsh
/usr/bin/chfn
/usr/kerberos/bin/ksu
6

Broadly I agree with frank_rizzo but you have yet again failed to state the Operating System or the intended purpose of the computer which you are "hardening".

If this server hosts say 10,000 user accounts you may find that hardening the permissions on the "passwd" command will keep you fully occupied with call tickets.

Your reference document is clearly for hardening the security of a RHEL database server in a student environment where hacking is a real danger.

General advice:
Do not change the SUID or SGID permissions on system commands.
However there is sometimes good reason to remove "other" execute permissions on certain commands because Linux "out of the box" will allow users to do things which are undesirable. Top of the list would be "mount". This assumes that you have allowed Shell access at all.