XACE and XSELinux patches for Xorg 6.8.2

Jim Gettys Jim.Gettys at hp.com
Fri Feb 25 09:11:59 PST 2005 

On Thu, 2005-02-24 at 16:55 -0600, Bryan Ericson wrote:
> Hi, Jim
> 
> Sure, that's fine.  Everyone here had a hard time understanding
> SELinux at first as well.  If you don't mind, I'm going to include two
> of my co-workers, Chad and Darrel, in the discussion as well, because
> they're more familiar with the SELinux security model than I am.
> 
> Basically, SELinux works as follows (please excuse me if I'm covering
> information you're already familiar with):

Nope, just trying to get my head around it now; I spent much of
yesterday digging up and beginning to read papers.

I'm cc'ing the list again, as I think the community needs to increase
its familiarity with the topic, though I expect to have to become
relatively expert.

> 
> SELinux uses security contexts to make its security decisions.  Each
> context is a colon-separated string of the form:
> 
> user:role:type:mls
> 
> where:
> 
> mls is (as you might expect) the traditional Multi-Level security
> information.  It contains the user's current level as well as the
> user's clearance.
> 
> type is a security attribute given to files, network ports, etc.  The
> word 'type' is often used interchangable with 'domain'.  Types, along
> with the mls component of the context, are used for making security
> decisions.
> 
> role describes the set of types a user is allowed to use. 
> Essentially, the domain a user is allowed to be in is determined by
> his role.
> 
> user is a user identity.  This does not necessarily correspond to a
> user in the sense of someone's login as it appears in /etc/passwd, but
> is instead defined in the SELinux policy.

Hmmm...  In order for X to become a multi-user window system (and it
needs to, and quickly, as cheap high resolution projectors are in the
very near future), it needs to have the concept of a user (and of a
user's session).  As X is network transparent, its concept of user is
probably likely to be something like an SSH key, or a kerberos
principle, rather than an entry in /etc/passwd, which isn't useful in
the X environment.

How might these concepts interact?

> 
> The 'SELinux policy' is the set of files that determine security
> decisions.  It is a compiled language that is loaded into the kernel
> at startup.  All users, roles, types, and mls information is
> determined by the policy.
> 

And how do security aware applications understand the current policy in
effect?  An application may need to be able to refuse to run if the
security policy in place is insufficient.

> When a security decision needs to be made, the kernel consults the
> policy, which determines whether the action in question is allowed or
> not, based on the context of the user's process and the context of the
> object it is trying to access.  SELinux denies all attempts to access
> data that are not explicitly allowed by the policy.
> 
> Implementation-wise, all security decisions are made in the kernel. 
> There is a user-space front end to this facility, which was created
> specifically for the X server by NSA and is used by the XSELinux
> extension.
> 

What's the performance overhead?  X operations are much less overhead
than a local system call. I once used to say in early X talks that 
"X is an exercise in avoiding system calls".

We certainly have to be able to make security decisions in user space
without a system call trap.  Is this cached in the user space library,
which might get notified if the security policy changes?  We can
certainly ensure that the X server get notified of such changes in a
timely fashion, though instantaneous revocation is probably not feasible
for performance reasons.


> 
> The XSELinux extension works as follows:
> 
> For every ClientRec structure, the extension creates a pointer to an
> XSELinuxClientStateRec structure and stores the pointer in the
> ClientRec's securityState member.  It fills out the XSELinux...Rec
> struct's security_id_t's, which are essentially structures that wrap
> the SELinux context strings.

We have to be careful when adding elements to data structures in the
server to do so avoiding unnecessary breaks in binary compatibility with
drivers.  If binary compatibility cannot be maintained, then we need
careful preparatory work with the graphics cards vendors for such a flag
day.

> 
> The XSELinux...Rec structure contains the members:
> 
> security_id_t sid;
> security_id_t rsid[NRES];
> struct avc_entry_ref aeref;
> 
> The sid member contains the context string that is assigned to that
> particular X client.  The rsid array contains context strings that
> correspond to various X objects that are associated with the X client,
> such as windows, drawables, etc.  The aeref member is used by the
> SELinux library to facilitate security decisions (the decisions are
> cached; this data helps speed lookups for cached decisions).

Ah, I guess this answers my question above.

> 
> The sid member is used for determining whether that particular client
> may access another client's data, while the rsid array is used for
> determining whether that client's data may be accessed by another
> client.
> 
> The structure is broken up in this manner so that different
> types of X objects may have different contexts.  For example, if we
> need to allow X client to access another client's graphics context but
> not its properties, then this can be explicitly allowed in the policy.
> 
> The context for each client is retrieved via the 'getpeercon()'
> function, seen in AssignClientState() in the XSELinux extension.  This
> function, again, was created by NSA explicitly for allowing SELinux
> functionality in the X server.

We'll need a similar kind of facility for remote clients.  Have any
clues about what to do in this case.

> 
> The XSELinux extension, in my opinion, still needs a little work; I
> was hoping to have a greater response to it on the xorg mailing list. 
> I may also submit the patches to the SELinux mailing list, which is
> somewhat more active.  I have some ideas on what needs to be fixed,
> and with input from the community I believe we can solve the issues in
> a satisfactory manner.

For this to go mainline in X, I suspect you'll need to meet the
following needs:
	1) be able to fully replace the X Security extension (people would be
unhappy about retrogressions).  I don't think we want two sets of ifdefs
in the server, and I'm happy to see in your patches that you are doing
it as a replacement.  Alternatively, data that shows the XSecurity
extension is in fact unused in practice, but as the CMW market doesn't
talk to us (or anyone, as far as I know), this data is tough to get, and
makes it hard for us to just make it disappear...
	2) be able to build on platforms other than Linux and provide XSecurity
functionality.  We are upstream of many systems, not just Linux, and
those platforms may care about XSecurity support.
	3) ideally, if the platform has support something like selinux, it
would be able to take advantage of it.  I gather from wandering on the
web, that some similar work has been done for some of the BSD's.
Not that you have to do this work, but if others do it, someone needs to
be responsible for the integration of support for those platforms.
	4) when not turned on, has very small performance overhead.
	5) when turned on, has tolerable performance overhead.
	6) won't make it more difficult to get to a situation where X can be a
multi-user window system (hopefully, it will be providing us with
facilities that make this much more viable)...

> 
> The thing I'm most concerned about is the hard-coded information in
> the extension (Eamon even provided comments to this effect).  At some
> point, this will need to be removed into the SELinux policy.

What kind of hard coded information?

> 
> Additionally, the implementation does not provide for protecting
> different objects owned by one client at different levels - for
> example, if a client has two properties and one contains SECRET
> information and one contains CONFIDENTIAL, the properties are not
> protected differently.  In order to accomplish this, pointers to
> security data would need to be added to every type of X object that
> would need to be protected, which would be a major bit of work.
> Again, Eamon provided a comment to this effect.

Isn't this necessary to meet the requirements of CMW, which is what the
XSecurity extension was providing?  Then again, I know little about the
XSecurity extension...

> 
> Finally, there is as yet no mechanism for an X client to update its
> context in the server. This behavior could be added fairly easily.
> 

And remote clients?  We'll also need secure channels from the client to
the server.

> I hope this overview has been helpful.  I probably didn't state some
> things as clearly as possible; please don't hesitate to ask questions.
> 
> Bryan
> 
> On Thu, 24 Feb 2005 16:10:10 -0500
> Jim Gettys <Jim.Gettys at hp.com> wrote:
> 
> > Bryan,
> > 
> > I'm finding getting my head around SELinux security model and how it
> > fits with X a bit hard at the moment....
> > 
> > Could we have a conversation to help with my conceptual
> > understanding?
> > 
> > Thanks,
> > 			- Jim Gettys
> > 
> > On Wed, 2005-02-23 at 12:09 -0600, Bryan Ericson wrote:
> > > Hello
> > > 
> > > Early last year, Eamon Walsh, while working for the NSA on the
> > > SELinux
> > > project, modified the X server to support SELinux.  In addition,
> > > he
> > > created a new extension: XACE (for X Access Control Extension). 
> > > He
> > > then modified the Security and Appgroup extensions to fit within
> > > the
> > > XACE framework, and created an additional XSELinux extension.
> > > 
> > > Basically, the XACE extension is a general-purpose security
> > > framework.
> > > Security-related extensions register themselves with XACE and
> > > specify
> > > which security-related events they are interested in.  When said
> > > events occur, XACE then calls functions within the extensions. 
> > > The
> > > operation in question succeeds only if the operation is allowed by
> > > all
> > > extensions.
> > > 
> > > Eamon's work was based on the 6.7 release.  Since Eamon left the
> > > NSA
> > > SELinux group, the CVS branch where he made his modifications has
> > > not
> > > been updated. We believe Eamon's work is an excellent foundation
> > > for
> > > future security work in X.  We have ported XACE and XSELinux to
> > > the
> > > current 6.8.2 release, and we submit it here for review and
> > > discussion, and for consideration for eventual acceptance into the
> > > mainline Xorg source.  The patches modify the xsecurity and
> > > appgroup
> > > extensions to use the XACE framework, change the direct calls to
> > > security extensions to calls into XACE, and add a new XSELinux
> > > extension.
> > > 
> > > About our interest in this project:  Trusted Computer Solutions
> > > (TCS)
> > > is working with NSA on the SELinux project.  We would like to see
> > > more
> > > security-related work done in the Xorg project, and we view this
> > > as an
> > > important first step towards future work on X security.
> > > 
> > > We welcome all constructive comments, discussion, and criticism.
> > > 
> > > Eamon's work is based on the following paper:
> > > 
> > > http://www.nsa.gov/selinux/papers/x11-abs.cfm
> > > 
> > > The patches can be downloaded from:
> > > 
> > > http://dgoeddel.home.insightbb.com/xorg-x11-6.8.2.xace.patch
> > > http://dgoeddel.home.insightbb.com/xorg-x11-6.8.2.xselinux.patch
> > > 
> > > Thank you,
> > > 
> > > Bryan Ericson
> > > Trusted Operating Systems Lab
> > > Trusted Computer Solutions, Inc.
> > > http://www.TrustedCS.com
> > > bericson at trustedcs.com
> > > _______________________________________________
> > > xorg mailing list
> > > xorg at lists.freedesktop.org
> > > http://lists.freedesktop.org/mailman/listinfo/xorg

More information about the xorg mailing list