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

[Bob Kleinberg]

Hello.  My name is Bob Kleinberg.  I have been watching your conversations for
awhile now since my program has a particular interest in what you folks are doing.
Let me say that
Ms. Walsh is beginning to touch on the area which I find of particular interest,
that is, distributed MAC.  With a single system, even if you make it a MLS-type or
a Compartmented workstation type, it does not live in a void.   With mail (like
this) and other collaborative services (IM, VTC, http, etc.) it is critical that
senders of information can be assured that the receivers are allowed to read the
information.  In other words, the secure kernel of one machine is just one element
of a community (not www) of trust.  With the advent of LDAP servers, and
Certificate Authorities, it becomes possible to create a community which utilizes
these services to ensure the identity and the access rights of individuals sending
and receiving information.  Thus, it is my assessment that unless these items are
built into the kernel as part of the TCB (Trusted Computing Base), the job of
building a secure BSD is incomplete.  I am not proposing any code level changes
here, just hoping to begin a dialog on the question of community of trust.  Some of
our folks here at TRW are working on a Windows NT variety of this but I think that
this needs to be at a broader, multi-platform level.  I would like to be able to
create a community which includes Unix-like / Linux / BSD systems, Windows NT
systems and, yes, Mac OS X systems (I am giving up on Mac OS 9 in this broad
context).   I welcome comments.

Thanx

Linda Walsh wrote:

> 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

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