Capabilities workshop, followup questions

[Bart van Leeuwen]

Well, if you create enough seperation between threads to actually allow
for such things you are ending up with something that starts to look petty
much like a process and not like a thread. I think that if threads within
a process cannot have a different security context, they should also not
be allowed to act on behalf of different users. Again, I'm not saying that
the model you use is not valid, just that imho it is not a thread what you
are using there, and shouldn't be called one.

Besides that, I believe the share by default environment between threads
in a process a too weak foundation for using threads securely in such a
way as you describe.
Forgetting a small thing in such an environment most likely leaves a hole.

In a shared when needed only environment such a thing most likely results
in a not working app, which is 1. more obvious to the coder, and 2. far
more secure ;-) 

I do not really believe that you can create enough seperation between
threads without ending up with reinventing most of what is already called
a process. Also I would argue that using this properly requires more work
from the coder and would result in almost as much overhead. 

hmm... I guess we just disagree and besides we do so based on slightly
different views on what a thread is imho. ;-)

Bart van Leeuwen
-----------------------------------------------------------
 mailto:bart at ixori.demon.nl  -  http://www.ixori.demon.nl/
-----------------------------------------------------------

On Mon, 19 Jun 2000, John Howie wrote:

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