XACE and XSELinux patches for Xorg 6.8.2

[Bryan Ericson]

Hi,

Comments included in line below ...

On Fri, 25 Feb 2005 12:11:59 -0500
Jim Gettys <Jim.Gettys at hp.com> wrote:

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

I would say that using the SELinux context's user field is not
appropriate for the scenario you describe above.  The reason is that,
as submitted, the SELinux extension has a hard-coded context that is
used for all non-local clients (this is, indeed, another item that
needs to be addressed).  The reason is that getpeercon() works only
for unix domain sockets, so all clients connecting via TCP are
assigned this hard-coded context.

The XACE framework, however, would facilitate development of a
security extension that assigns a unique ID to all users, which would
allow the functionality you describe.

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

Currently, there is no way for an application to differentiate between
a 'sufficient' and 'insufficient' security policy.  The sufficiency of
the policy is left to the determination of the system administrator. 
An application is able to determine whether SELinux is in effect,
however, and can perform appropriately once this determination has
been made.

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

As for the XACE framework, the overhead is very minimal.  We've not
done any rigorous performance testing, but I believe the performance
impact is negligable.

SELinux, on the other hand, does incur a performance penality.  This
is generally recognized and accepted by the SELinux community.  There
has been considerable work in reducing the time needed to make a
security decision, but the performance hit is unavoidable.  The
decisions are cached by the SELinux library.  When the policy is
reloaded, the cached decisions are discarded.

An additional problem is as follows:  the X server stores context
strings.  If the policy is modified so that components of the context
strings are removed and the policy is then reloaded, those contexts
stored in the X server will then be invalid and any attempt to make a
security decision using those contexts will be rejected.  This problem
is not unique to the X server, however; all user-space applications
will have the same problem.  In general, the system administrator
should be aware of the ramifications of reloading a new policy.  If
the policy is modified so that only new information is added, the
decision cache will still be flushed, but the problem of invalid
contexts will not occur.

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

Unfortunately, one of the consequences of the XACE framework is that
it requires the ClientRec structure to be modified.  In the current
implementation, this is unavoidable.

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

See my comments above.  Again, this is one area that needs a little
research.  Personally, I believe getpeercon() could be modified to
return a context based on the peer's hostname, as loaded into the
security policy.  I am open to additional suggestions.

> > 
> > 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 XACE framework does an adminable job of maintaining the current
functionality of the X Security extension without incurring
substantial overhead. While we haven't run a full test (we were unable
to find a test suite), I believe the functionality is unchanged.  XACE
allows additional security modules to run alongside the current X
Security extension - XSELinux is one example. While we don't have the
resources to test on even a large fraction of the platforms that X
supports, I believe XACE will compile and run without modification on
most if not all of them.

In the current patch, XSELinux is turned off by default in X11.tmpl. 
It is up to distributors or individual users to turn it on if they
desire the functionality it affords.

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

If look in the XSELinux extension, the top of the file has several
large arrays that look like:

static char *extensionTypes[] = {
    "BIG-REQUESTS",		"std_ext_t",
    "DOUBLE-BUFFER",		"std_ext_t",
    "DPMS",			"screensaver_ext_t",
    "Extended-Visual-Information",	"std_ext_t",
    "FontCache",		"font_ext_t",
    "GLX",			"std_ext_t"
    ...

These are SELinux domains, which really belong in the security policy.
The names of the domains should be completely abstracted away into the
policy.  Also, I've already mentioned the hard-coded context for
remote clients...

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

Unfortunately, our knowledge of the XSecurity extension is far from
complete as well.  Documentation and code examples are few are far
between.

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

As mentioned, the current XSELinux has problems handling remote
clients.  This is being investigated, though we are always open to
suggestions ...

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

Regards,

Bryan Ericson
Trusted Operating Systems Lab
Trusted Computer Solutions, Inc.
http://www.TrustedCS.com
bericson at trustedcs.com