SGID and SUID Bits set on files and directories issue

Hello, everyone..I running Sun Solaris 8 and I wanted to know all the directories/files with SGID and SUID bit set. So I ran a find on 02000 and 04000 to find all files and directories with sgid/suid bit set...I saw the list and I wanted to know how can I determine what files/directories are needed by the sgid/suid for the OS to run properly...What I want are the files/directories that don't need the bit set. How can I determine what to change and what not to change????
Menace212Asked:
Who is Participating?

[Webinar] Streamline your web hosting managementRegister Today

x
 
neteducationConnect With a Mentor Commented:
>> Well, it could use a bit of polishing, but ... :)  One thing that occurs to me, though.. will sudo allow you to limit the arguments that are passed to the command, i.e. to prevent someone from executing "sudo passwd root"?

Yes you can limit it. However I'm not sure if

sudo passwd

will really work on all OS's. The passwd command may not know who's password to change, as the euid/uid might be changed to root, therefore the passwd command may not recognize the user anymore.

Also, unless you specify each user in sodoers, usera would be able to do "sudo passwd userb" which may not be to desirable.

As for the original Question:
 >> What I want are the files/directories that don't need the bit set. How can I determine what to change and what not to change????

This depends very much on how you define "don't need". Let's take the well-quoted passwd as an example. Suppose you dont need that your users can change their passwords, then you can take the bit of. This is valid for most suid-files.  
If you wanted to be sure, you would need to go for each of the files and check for yourself if you need the apropriate functionality. However this could be quite time-consuming.

A good choice may be to run some hardening tool over the system, it will switch off the SUID on most programms where "normal users" dont need it.
0
 
ahoffmannCommented:
SUID on directories is not defined (some exceptions on some OS' probably)
SUID on programs i.g. is not bad, just if the owner is root
on modern OS you should not need SUID programs. use sudo for that

SGID on directories has no disadvantages (except for some users, which is the purpose of this permission:)
SGID on programs is similar to SUID on programs

The sticky bit is useless for files on modern OS, on directories it's an security enhancement.

According security you only have to think about SUID and SGID on programs (or scripts), you need to check your OS' docs which are necessary for a proper functioning OS.
Userla there exist special hardening scripts for an OS to do the work.
0
 
PsiCopCommented:
Generally, SUID is used to allow a program to escalate its privledge. As ahoffman noted, this is widely considered to be potential security hole, and is frowned on. In Solaris 8, the biggest offenders are the r* programs (rsh, rlogin, rcp, rexec, etc), which by default are SUID root. Most environments disable the r* services on their Solaris servers,  and hence there is no reason for the r* programs to have the SUID bit set (leaving it set, even when the corresponding services have been disabled, can still lead to system compromises via buffer overflows or other holes, since the execution would occur in the root security context).

See the Center for Internet Security Solaris Benchmark, which is a good guide to hardening Solaris, and covers Solaris v8 quite well. Along the way, it specifically touches on SUID/SGID programs, and includes a script to hunt them down on the system. See the Center's website at --> http://www.cisecurity.com/ (i'd provide a direct link to the Benchmark, but they request folx not do that).

Also, in /etc/vfstab/ you can mount filesystems with the "nosuid" option, which causes Solaris to ignore the SUID bit for that filesystem. This is very handy if you have separate partitions for /var, /home and/or /export/home. Even is someone somehow contrives (perhaps via NFS) to have an SUID program in their home directory that's owned by root, no privledge escalation will occur. Same thing for unprivledged processes writing to /var. Be careful, of course, to not apply that option to /usr or /.
0
SMB Security Just Got a Layer Stronger

WatchGuard acquires Percipient Networks to extend protection to the DNS layer, further increasing the value of Total Security Suite.  Learn more about what this means for you and how you can improve your security with WatchGuard today!

 
PsiCopCommented:
*chuckle* This just reminded me I haven't gone and removed the SUID bits from the r* programs on my new Solaris 8 server. Gotta go do that.
0
 
macker-Commented:
There are times when setuid/setgid is either necessary or useful for a program.  E.g. if you want a user to be able to access a CD-Recorder device thru software that has built-in access restrictions; the device needs to be accessed as root, but you don't want to give the user root access.  IF the software is specifically designed to be operated setuid root, then this should be safe.  sudo is an excellent utility, but some software just needs elevated privileges to function properly, and use of sudo should not be generically required or considered a replacement for setuid/setgid.

Directories that have the sticky bit set are to assign proper permissions to files automatically.  Removing the sticky bit on directories will not improve security.  It can be a good idea to remove setuid/setgid bits from programs which you know will not need to be run by non-root users on a server, or where you wish to restrict it to specific users via sudo... this is advantageous to security ONLY on the presumption that there may in fact be security flaws in these programs that could be exploited in the future.  The same argument serves for disabling services which are not needed.
0
 
TintinCommented:
"SUID on programs i.g. is not bad, just if the owner is root on modern OS you should not need SUID programs. use sudo for that"

Not a good idea to remove SUID bit on /bin/passwd ;-)





0
 
ahoffmannCommented:
>  Removing the sticky bit on directories will not improve security.
what do yxou mean by that?
removing the sticky bit from directories makes it possible that other users delete files without being the owner

> Not a good idea to remove SUID bit on /bin/passwd ;-)
ACK.
but if there is only sudo with SUID bit, then there is a single point of failture ;-)
0
 
macker-Commented:
It should not be possible to remove files that are in a sticky-bit directory unless the file itself has permissions allowing it to.  Setting proper file permissions for security is still a requirement, as is choosing the correct directory to write files to.  If sticky bit was incorrectly set on a directory, then removing it may improve security by preventing bad permissions from being inherited, but I wouldn't advocate removing sticky bit from all directories in an attempt to improve security.
0
 
PsiCopCommented:
Tintin, if you invoke /bin/passwd via sudo, I don't think it'd need the SUID bit. :-)
0
 
TintinCommented:
Invoking /bin/passwd via sudo will work *if* you type it in from the command line, however, if your password expires when you try to login, you could be stuffed (depending on your Unix flavour)
0
 
macker-Commented:
Sounds like a convenient way to rid yourself of annoying users...

User: "I can't login!  It gives me an error about passwd!"
"Yes, your password expired."
User: "But how do I change it?"
"You can change your password using sudo.  The system issues warnings when your password is close to expiring."
User: "Okay, but how do I fix it now?"
"You'll need to run sudo to change your password."

Well, it could use a bit of polishing, but ... :)  One thing that occurs to me, though.. will sudo allow you to limit the arguments that are passed to the command, i.e. to prevent someone from executing "sudo passwd root"?
0
 
ahoffmannCommented:
> sudo passwd
will change roots password, bettter use:
  sudo passwd $USER
and sudo can be configured for special command too

But that's all a bit OT, can we focus on the SUID SGID.
0
 
PsiCopCommented:
Which came first, the chicken or the egg? :-)
0
All Courses

From novice to tech pro — start learning today.