Re: suidpid( UID, credential? ) ? secure IPC?

kwrohrer@enteract.com
Wed, 8 Oct 1997 00:28:25 -0500 (CDT)

And lo, Jim Dennis saith unto me:
> > And lo, Jochen Friedrich saith unto me:
> >> kwrohrer@enteract.com wrote:
> >>> And lo, Jim Dennis saith unto me:
> >>>> I was wondering if there is any mechanism for having some
> >>>> process (a daemon or kernel module perhaps) "touch" a process
> >>>> and set its *real* UID to a different value.
> >>> Probably not.
> >>>
> >>>> Would it make sense to add a suidpid() call?
> >>> What happens if, after authentication, the process dies and another
> >>> process pops up with the same PID? Hard to do nowadays, but I don't
> >>> believe it's guaranteed impossible, especially given some way of
> >>> bogging the authenticator down at the right moment...
> >>
> >> I don't see this problem when the kernel handles this problem:
> >> - program calls kernel seteuid_auth(authinfo)
> > If you're going to do this, either you've got to make some special new
> > kernel-to-user communication system, or you may as well make the
> > authenticator a kernel module.
>
> I figured this might be the case and asked if there was
> any existing kernel/process IPC mechanism that would
> suffice.
>
> Perhaps we need ways of "registering" and querying a set of
> "kernel services."
I would rather see fine-grained permissions, as the POSIX 1.e(?)
sub-thread suggests.

> Could it be done as a device driver? A feature of the
> proc filesystem?
Probably a very simple pair of bitmask-getting and bitmask-partial-
clearing system calls; the bitmap could be kept with the rest of
the process/thread descriptor. The current setuid/setgid bits would
essentially turn all these finer bits on (as appropriate, for
setgid and for what uid it sets to); any intended-for-setuid
program which wants to make use of this feature should release all
undesired priv bits anyway, regardless of what the filesystem says,
and if it doesn't, we're no worse off than with setuid root now...

I was considering suggesting that these bits just refine the standard
setuid/setgid bits (e.g. I could set a bit so that do_something runs
with just the file-reading permissions of my group, but no other
extended privs), but since there aren't many privs which aren't root-
specific, that doesn't seem necessary.

What would be cute, is uid>0 accessible add-group and add-user-to-group
software; this would be hard to fortify against abuse, but would be the
closest to ACL's one could (portably!) come for some time... This is
kind of off the topic, though.

> >> A process can't be killed while it is blocked in the kernel.
> > You don't want to allow this if you can possibly avoid it.
> > Unkillable processes are bad(TM)! Even if they're not doing
> > anything but cosmetically increasing the load average and taking
> > up a PID. There are some things (e.g. stock 2.1.57's lockd)
> > which accidentally get into this state, but I can't think of
> > anything but init that can't (or, at least, shouldn't) be
> > killable in a properly working UN*X environment.
> I agree. However, the kernel can maintain the list
> of "locked PID's" -- and "unlock" that PID as soon as
> the "auth" request is cancelled.
The immortalizing has to be atomic with the request, and the remortalizing
has to be done after the request is acted on or rejected. It really
sounds like it would be much, much easier and cleaner to have the
"authenticator" in this picture actually do the work, which reduces
the whole problem to a user-level secure IPC/RPC protocol.

> >> The kernel would need to check the authenticator and i.e. signal
> >> init if the authenticator dies.
> > You want not only a new system call, but a new communication method,
> > a new task for init, and error checking for all of the above? A
> > larger hammer will not help with pounding in this particular screw,
> > IMHO...
> Then please describe a screwdriver that will fit its head and
> give us the required torque.
An allen wrench, I think, with as little torque as will do the trick.
I like the fine-grained-priv bits bit. Simple query-privs and release-privs
system calls, complemented eventually by corresponding setpriv bits in
the filesystems, should do what you want for the predefined privs in
a simple and reasonably elegant way. This is quite easy to do in a
simple, robust, and verifyable (or at least understandable, unlike some
things the kernel does) manner. Programs are authenticated, and
privs are amplified, at "chmod" time by the superuser; there's nothing
for the computer to have to authenticate or verify.

Anything you can't predefine as a particular priv in the kernel, should
be done by secure IPC/RPC to an appropriately privved server, IMHO.


Keith