[9020] in bugtraq
Re: setuid vs. setgid (was Re: Anonymous Qmail Denial of Service)
daemon@ATHENA.MIT.EDU (Pete Kruckenberg)
Sun Jan 10 14:33:53 1999
Date: Sat, 9 Jan 1999 12:21:59 -0700
Reply-To: Pete Kruckenberg <pete@KRUCKENBERG.COM>
From: Pete Kruckenberg <pete@KRUCKENBERG.COM>
To: BUGTRAQ@NETSPACE.ORG
In-Reply-To: <E0zyhRE-00013T-00@ursa.cus.cam.ac.uk>
On Fri, 8 Jan 1999, Nick Maclaren wrote:
> This isn't pedantry - it is a real problem.
>
> Consider things like job schedulers, printing systems and so on. User
> A calls one of those, which runs as user B. It then calls mail - the
> examples were chosen because both of them do precisely that. Which
> is the user identification that the mailer should use?
>
> There are many possible 'solutions', but none are satisfactory. For
> example:
It would seem like one possible solution would be to treat setuid like a
directory structure, so could build "absolute" setuid "paths". getuid()
would return either the real id of the current process, or the list
(array) of real ids back to the "root" (the one owned by root, not the
first process) process (like the directory structure has a root at /).
I think this could be set up in the Unix kernel to operate seamlessly in
the way that setuid/getuid normally work, but also allow extended
functionality for better process security.
I think this would only require minor modifications to the process table
(replace the uid/gid piece of the task structure with a pointer to a list
of uid/gids). So instead of getuid() returning current->uid, it would
return current->uid->uid, for example.
Looking at the Linux kernel code, it doesn't look like this would be
incredibly difficult to do. Of course, any programs that want to use the
extended functionality of getuid() would have to be rewritten. And I'm
probably overlooking a hundred details...
Pete Kruckenberg
http://pete.kruckenberg.com/resume/
