Capabilities workshop, followup questions

[Bart van Leeuwen]

On Mon, 19 Jun 2000, John Howie wrote:
> 

... snip ... 

> 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.

I agree that scheduling should be done by thread and not by process, that
would imho enhance efficiency quite a bit.

What I however disagree with is that allowing threads to have its own
security context is solving much.
The problem I see is that threads belonging to the same process are
usually also running within the same address space. That is an advantage
when using threads since it makes resource sharing and the like easier and
more efficient, but I find that a rather dangerous situation when
different threads with different credentials share a single address space.
In such a situation the inevitable small bugs that statistically will
exist in the code that handles that can lead to far more severe problems
then when those 'threads' are nicely seperated.

I understand the problem you describe, and I agree that that needs to be
addressed, but I still don't believe threads are the way to address
it. ;-)


> 
> 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.

Yep, I can understand that, and imho such an app shouldn't use threads
for that purpose ;-)

Things requiring different credentials should be seperated quite
strictly. Having them share more then strictly needed for them to function
is imho a security disaster waiting to happen.

> 
> Feel free to completely disagree :-)

I do ;-)
Oh well, I guess I should shutup now before I start talking real nonsense
(if I didn't do so already ;-)

Bart.

To Unsubscribe: send mail to majordomo at trustedbsd.org
with "unsubscribe trustedbsd-discuss" in the body of the message