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

[Robert Watson]

On Wed, 30 Nov 2005, Mark Seaborn wrote:

>>>> Based on your description, I don't think XSELinux would work for you. 
>>>> Access control in SELinux is based on access rules in the security policy, 
>>>> which cannot be modified on the fly.  Thus, if your app has access to 
>>>> another app, then it will always have that same level of access, and a 
>>>> given application has no control over which apps have access to it.
>>> 
>>> I'm curious, do the SELinux folks see this as a drawback of SELinux?
>> 
>> Actually, it's seen as an advantage.  It prevents a malicious program from 
>> attempting to escalate its own privileges.  Also, it allows for very 
>> predictable behavior, which is always a good thing for security.
> 
> 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. 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.  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).

Likewise, in the various CMW/MLS X11 systems (from TMach and Trusted X 
through Trusted Solaris), the operating system level MAC constraints are 
extrapolated up the application stack and also enforced in the X server by 
carrying labeling information both "out of band" on the IPC primitives 
between clients and the X server, and "in band" in the form of explicit 
label related X protocol extension operations.  The protections in X11 are 
simply an extrapolation of the underlying security model in the operating 
system, in which the X server (or related mechanisms) play a part in 
enforcement.  Without the underlying OS protections, the X11 protections 
would be ineffective, as they could be bypassed through other IPC or 
debugging channels -- on the other hand, without the X11 protections, the 
applications couldn't be used together, or the OS protections would have 
to be disabled.

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.  One of the things I don't yet have much of a grasp of is how XACE 
and security plugins that use it will interact with X extensions.  We live 
in a world where X extensions are a critical part of almost all current 
use (render, etc), and so any X security work must take into account the 
operations, objects, communication, etc, that occurs in extensions.  My 
worry from brief readings of the patch (and no real experimentation yet) 
was that there was quite a bit more work to do in integrating with the 
off-the-shelf extensions required for regular use.  This could be a false 
impression, however, as I'm really only starting to dig into XACE, and 
other than the sample conversion of the SECURITY extension to use XACE, 
there isn't much in the way of documentation as to how it might be used 
yet :-).  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.

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

Robert N M Watson
University of Cambridge