Capabilities workshop, followup questions

[John Howie]

----- Original Message -----
From: "Bart van Leeuwen" <bart at ixori.demon.nl>
To: "John Howie" <JHowie at msn.com>
Cc: <posix1e at cyrus.watson.org>; <trustedbsd-discuss at trustedbsd.org>;
<linux-privs-discuss at sourceforge.net>
Sent: Monday, June 19, 2000 4:41 AM
Subject: Re: Capabilities workshop, followup questions


> On Sun, 18 Jun 2000, John Howie wrote:
>
> >
> > ----- Original Message -----
> > From: "Bart van Leeuwen" <bart at ixori.demon.nl>
> > To: <posix1e at cyrus.watson.org>
> > Cc: <trustedbsd-discuss at trustedbsd.org>;
> > <linux-privs-discuss at sourceforge.net>
> > Sent: Sunday, June 18, 2000 3:38 PM
> > Subject: Re: Capabilities workshop, followup questions
> >
> >
> > > This would imply that a thread can execute, but that any capabilities
and
> > > resources used should be checked against the process that 'owns' the
> > > thread.
> >
> > Won't, and shouldn't, work. What happens if you have a daemon that
listens
> > for incoming work requests from clients and creates a thread to process
each
> > request. Now imagine what needs to happen if the thread must run in the
> > security context of the client. It needs to perform a seteuid (). Should
> > resource access be checked against the uid of the process? Emphatically,
no.
> > The process will have a different uid and might not have access to the
> > resources that the thread should. All resource access, and accounting,
needs
> > to be performed at the thread level.
>
> Uhm... or such a definition of threads would mean that you cannot do
> something like you describe with them and need to find a better way to do
> that. My question remains, why not make it a process when you gonna do
> things that are process like with it.

The problem with using processes is that the traditional model is something
like:

while (1) {
    listen (s, 5);
    n = accept (s, ...);
    pid = fork ();
    switch (pid) {
        case 0:
            /* I'm child */
            DoBecomeClientUser ();
            DoProcessRequest ();
            exit (0);
            break;

        case -1:
            /* didn't work */
            ...
            ...
            break;

        default:
            /* I'm parent... do wait or something */
            break;
    }
}

Apart from the fact that the above code is terrible the problem is that you
have to create a whole new process, with all the overhead that it entails,
to process each request. It would be far simpler to create a new thread and
allow that thread to have its own state, including registers and security
context. I'll also go so far to say that the system should be scheduling
threads in a process, and not processes. It would provide a much more
efficient model.

If access to resources is governed by the security context stored at the
process level, in the pcb, then the scenario I originally outlined would be
a security nightmare. Can you imagine auditing a large multi-threaded
application for correct handling of set(e)uid ()/set(e)gid ()? If we go
forward and build a system that allows programmers to easily create insecure
applications, no-one will take it seriously.

Feel free to completely disagree :-)

john...




To Unsubscribe: send mail to majordomo at cyrus.watson.org
with "unsubscribe posix1e" in the body of the message