[H-GEN] okie just what I sort of need to know

[Ben Carlyle]

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


Morning,

A more complete explaination follows:

SUID stands for Set User IDenditifcation, and has a close companion SGID
for Set Group IDentification.  These are backdoors in the UNIX security
model that permit programs to do things as users other than the one who
started them.

The normal case,

In order to become a normal user at login, a root-owned login process
verfies the identiy of a particular individual.  Once the root-owned
process is confident that you have the right to access a particular
account, it calls the priveleged setuid(2) system call.  Once the
login process has made this call it cannot return of its own violition
to root ownership, and thus can never be a root process again.

init(root) --spawns--> login(root)--setuid-->login(user) --exec--> shell(user)

The loophole,

So how does "su" work?  How can a user effectively become someone else for
a particular operation without logging back in via a telnet or other root-
owned process.
Well, this is where SUID comes in.  When an executable is owned by root
and has the setuid bit present, any user who has permissions to run
that executable will assume the effective userid of root as it is started.
Note that UNIX security is process-based, so this only affects the
particular process with a setuid bit.  It cannot make old processes live
again as different users, and it cannot make your other processes betray
the system.  That process started with a setuid bit in place will run
as the user that owns it.  This user is often root.

shell(user1) --spawns--> su(root)--setuid-->su(user2) --exec--> shell(user2)


In a well organised system few commands really need to be setuid root.  In
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
reason that you are giving anyone who has execute permissions the right to
run a particular program as you.  A common old trick to obtain a perminant
backdoor to a system was to plant somehow a setuid binary in a hard-to-find
location and simply execute it (bypassing the usual logging associated with
a login process), although this it is rare these days since countermeasures
using siple checks are freely available.  Any binary that is setuid or is
run by a setuid program should be simple, and not prone to buffer overruns.
A setuid program should be considered at a risk level near that of network
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 be
able to run it as root, use "su -c", or use the more sophisticated "sudo"
command to achieve the same results.  If you're not worred about the
security aspects on the other hand (and I suspect they mean little to you
at this time), just setuid and let her rip.


> >3. what is SUID I assume it stands for SuperUser ID

On Sat, Sep 11, 1999 at 10:55:21PM +1000, Allen Grace wrote:
> Look at the permissions after you do the above. The s denotes that when
> run by users other than root, the process is allowed to assume a UID of
> 0, i.e root, and do privileged things.


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