Fine-grained access control -- XACE, XSELinux and X security (fwd)

[Mark Seaborn]

Robert Watson <rwatson at FreeBSD.org> wrote:

> On Wed, 30 Nov 2005, Mark Seaborn wrote:
> 
> > The problem is that it's not always possible to tell in advance what 
> > authority an application should have.
> > 
> > Take an e-mail application, for example.  You might need to give it read 
> > access to a file to be sent as an attachment.  If there isn't a way for the 
> > user to grant this access dynamically, the user will have to run the 
> > application with access to all of their files, because they won't know in 
> > advance (when the app is installed or launched) which of the files it might 
> > need.  This obviously violates the principle of least privilege/authority. 
> > This is what I'm trying to address with the powerbox mechanism.
> 
> Presumably for any X/GUI security mechanisms to be effective, they have to 
> be tied to an integrated set of security constraints up and down the 
> operating system and application stack, as without either a strong set of 
> assumptions or a strong set of protections, the windowing system is just 
> one level of many in which inter-application communication (and hence 
> compromise) can take place.

Yes.  I have already got a mechanism for limiting the authority a
process gets at the OS level -- this is what Plash does.  It deals
with granting limited access to files.  It limits a process's
authority by giving it a dynamically allocated UID and chroot()ing it
to a virtually empty chroot jail.  It dynamically links programs with
a replacement libc.so.

The reason for taking this approach is to make it as widely accessible
as possible.  It doesn't require a specially-patched kernel.

Having done this, I just need to plug the hole that X leaves.

Polaris is in a similar position.  It is a system which limits the
authority of programs run under Windows by running them under
different UIDs.  However, Windows' window system (like X) allows
processes to send events to each other, allowing them to fake key
presses, etc.  The people working on Polaris have been looking for a
way to prevent this.  I think they had some success but I'm not sure
what the outcome was.

> For example, the XSECURITY extension is modeled on a
> "trusted/untrusted" environment, in which the underlying assumptions
> are that a few untrusted applications, perhaps tunneled through an
> application firewall, are permitted limited rights to display in the
> same display as "trusted" applications.

Is that what it's supposed to be for?  I've only seen the
documentation for the extension itself and I don't think it explained
what the intended use was, and it didn't look very useful, seeing as
it only provided two protection domains.

> Without this notion of where the applications "come from" (by virtue
> of new authorization cookies handed out as appropriate, perhaps to
> firewall tunneled X sessions), there would be insufficient
> information at the X11 layer to make policy decisions, and
> applications could bypass the windowing layer protections (i.e., if
> executed on the same host as the same user).

This "comes from" notion would be fairly straightforward with Plash.
You just give each application a different /etc/.X11-unix/X0 socket
object for opening X connections in an isolated X protection domain.

> One of the things I like about XACE is that it appears to offer a lot of 
> flexibility to integrate with whatever underlying security model is being 
> used, and avoids committing to a particular security approach in the X 
> server.

I think this is both good and bad.  XACE is not really an extension,
in my view, because it doesn't provide an externally-usable interview.
It's a patch that provides some internal hooks.  In order to use XACE
you need to build your own X server.  It reduces the cost of isolating
X clients a little, but not much.

> I would also be very interested in knowing, for example, whether 
> the Trusted Solaris X11 security enhancements can be expressed using an 
> XACE extension easily.

Is there any public documentation on Trusted Solaris's X11 security?

> What sort of underlying OS and application security framework are you 
> looking at to supportthe application behavior you describe?  The trusted 
> window system work by Jonathan Shapiro (et al) for EROS describes 
> something similar to what you have in mind using the EROS capability 
> mechanism -- i.e., the granting of rights to an object by passing the 
> capability for it as a result of a set of events layered over the 
> windowing system.

It's no coincidence that EROS is similar because EROS and the other
capability systems (such as the E language) are what inspired me to
work on this in the first place.

Plash uses a capability system; it has a protocol for transferring
object references between processes.  So far this hasn't been exposed
much -- there is a C interface but it's not properly documented yet.

> I've started to look at using a constrained execution 
> environment similar to a capability mechanism using the TrustedBSD MAC 
> Framework on FreeBSD, but avoiding a commitment to an overall operating 
> system restructuring to be capability-oriented.  However, I haven't gotten 
> all that far up the application stack yet.  It would be interesting if 
> what you have in mind and what I have in mind could meet in the middle.

I'd be interested to hear more about what you have in mind.

Mark