[Linux-privs-discuss] Re: Capabilities workshop, followup questions

[Linda Walsh]

Maybe for purposes of having a server, you have something like a 'fsuid'
but maybe it should contain whatever else a server process needs to do
its accesses as the end user -- something like a "credential structure"?

With MAC, you have a similar problem -- server processes are going to
need to run with the MAC label of the client to do file accesses.  

Just like 'root' can be respected if coming from a particular system, what
about 'capabilities' if coming from a particular system?  I.e. if a
user has 'CAP_DAC_READ_SEARCH' another system should be *able* to honor
that and allow the user same privs on an exported partition (as well as
the contrary -- disallowing or ignoring remote-user capabilities).

--
Linda A Walsh                    | Trust Technology, Core Linux, SGI
law at sgi.com                      | Voice: (650) 933-5338                        


> -----Original Message-----
> From: linux-privs-discuss-admin at lists.sourceforge.net
> [mailto:linux-privs-discuss-admin at lists.sourceforge.net]On Behalf Of
> Bart van Leeuwen
> Sent: Monday, June 19, 2000 2:30 PM
> To: John Howie
> Cc: Jon Tidswell; posix1e at cyrus.watson.org;
> trustedbsd-discuss at trustedbsd.org; linux-privs-discuss at sourceforge.net
> Subject: [Linux-privs-discuss] Re: Capabilities workshop, followup
> questions
> 
> 
> 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...
> > 
> > 
> > 
> > 
> > 
> 
> 
> _______________________________________________
> Linux-privs-discuss mailing list
> Linux-privs-discuss at lists.sourceforge.net
> http://lists.sourceforge.net/mailman/listinfo/linux-privs-discuss
> 
To Unsubscribe: send mail to majordomo at trustedbsd.org
with "unsubscribe trustedbsd-discuss" in the body of the message