Capabilities workshop, followup questions

[John Howie]

----- Original Message -----
From: "Jon Tidswell" <jont at zip.com.au>
To: "Bart van Leeuwen" <bart at ixori.demon.nl>; "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 1:25 PM
Subject: Re: Capabilities workshop, followup questions


> I think the argument Bart is making is that two threads sharing an address
> space necessarily share a security context.

I believe the argument to be flawed. If a thread is able to impersonate a
client through set(e)uid () without changing the context for the entire
process then the stack and context allocated to the thread can be protected
from access by other threads in the same process if it is deemed necessary.

>
> My "take" on per thread security data in the kernel is as follows:
>
> If the process is _trusted_ then we may trust the threads when they say
> "I act on behalf of <x>",  and per thread security data is not needed in
> the kernel.

I have to disagree. When a system call is made, the security context of the
thread making the call is important. Besides, how do you propose to trust a
thread when it says that it is acting on behalf of <x> without maintaining
some form of security context at the thread level.

Take the hypothetical example of a multi-threaded Web-server that allows
users to authenticate themselves. For each request, a thread is either
created or taken from a pool of standby threads. In either case the thread
performs a set(e)uid () to impersonate the user before opening the page, or
cgi-bin file, requested. The theory is that the system is then responsible
for checking resource access by the clients either explicitly through access
() or implicitly when calling open () or exec (). This only works IF there
is per-thread security context.

Now, imagine what happened if there is only per-process security context.
Thread 1 is created to process a request from User A, and Thread 2 is
created to process a unit of work from User B. Thread 1 successfully calls
set(e)uid () to impersonate User A, the scheduler then switches to Thread 2
which calls set(e)uid () for User B. Now suppose the next thread scheduled
in the process is Thread 1, again. When Thread 1 is running it resumes
processing User A's request which just so happens to be a cgi-bin file. The
security context of the exec () is now User B because context is maintained
at the process level.

The problem would be tremendously exacerbated in a MAC environment where you
have to track a subject's security level too.

> If the process is not trusted, then it is not safe to assume that
different
> threads maintain separate security contexts, and per thread security data
> is not needed in the kernel.

You differentiate between trusted and untrusted processes. I believe this to
be dangerous. If the fundamental programming/processing model is flawed then
you can never have a trusted process. With the correct mechanisms in place,
all processes can be trusted (this is different from the user trusting a
process). To put it simply, the resource that is scheduled needs to have its
own security context. As we would (hopefully) be scheduling threads it is
necessary to maintain thread security context.

Anyone have a third viewpoint?

john...




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