[H-GEN] SUID, and Unix groups [long] [was: okie just what I sort of need to know]

[Byron Ellacott]

[ Humbug *General* list - semi-serious discussions about Humbug and
Unix-related topics. ]

[snip good explanation of suid, sgid, and the reasons for them]

>a well organised system even most setuid programs could be owned by less
>critial users such as "ppp".  Setuid -is- a security risk for the simple
>daemons, especially on multi-user machines.  In the case of kppp, although
>I have not used it, it sounds to me that the intention of an SUID bit is
>that any user can start the program and connect the the net.  You may

Along these lines, I'd like to point out a very underused feature of the 
Unix security model -- groups.

-rwxr-x--- 2 user  group        .....

The important bit here is the middle part of the permissions, those for 
group.  In the example above, it is desired that a group of users should be 
able to dial the modem; however it is often the case that not all users 
should be able to.  There are several problems with making a world 
executable suid-root binary.  The first is the possibility that the program 
is insecure; I'm not going to dwell on this.  The second is that making the 
program runnable by *anyone* is using a tactical warhead to do the job of a 
board-with-a-rusty-nail.

-rwsr-x---   1  root  dialup    653423 Sep 13 11:12  kppp  [0]

This permission model keeps kppp as a setuid binary, but now the only people 
who can execute it are either root, or members of the dialup group.  This 
means someone finding an exploit in your CGI script can't run a buffer 
overflow attack on your setuid executable, because your (properly 
configured) CGI system runs CGI scripts as "nobody".

The use of this applies even further when you apply it to things such as DOS 
filesystems.  Say you have a DOS filesystem on /dev/hda3, and you want to be 
able to write to it as your main user, say "bje", and a trusted user, say 
"davidj". You'd also like to let other users on your system read from it.  
One way is to make it writable to everyone and hope the other users on your 
system are trustworthy.  Another, saner, way is to give sudo access to bje 
and davidj.  But sudo can only be told to give access to certain programs, 
not certain filesystems.

The solution?  Put "davidj" and "bje" into a group, and mount /dev/hda3 as 
being owned by that group, with a 664 mask.  You could do a 764 mask, mount 
/dev/hda3 as owned by root, and provide sudo access to /mnt/point/* for 
execution.

Groups can also be used to allow your standard user access to /dev/dsp, 
/dev/mixer, /dev/cdrom and /dev/audio, without letting, say, "davidj" telnet 
in and play Aqua for you at 3am, setting volume to maximum.

The point of this?  setuid is a very broad tool; in many cases setting 
appropriate group permissions avoids the need entirely, and the concept is 
generally useful in many other places.[1]

--
bje

[0] This is a contrived ls -l output; I am anti-kde. :)
[1] Wishing that the cello sysadmins had used groups for group assignment 
work instead of a hacked up su-type command that made the whole process 
awkward and ugly.

______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

--
This is list (humbug) general handled by majordomo at lists.humbug.org.au .
Postings only from subscribed addresses of lists general or general-post.