XACE and XSELinux patches for Xorg 6.8.2

[Jim Gettys]

On Fri, 2005-02-25 at 14:30 -0600, Bryan Ericson wrote:
> > > 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.

Right now, most sane people disable direct access to the X server
entirely, depending on SSH for remote access; this has the property of
making all remote access look as though it is local (as it is in fact),
since the ssh daemon process is local.

I'm not happy about the use of SSH as an all purpose hammer (though it
is one hell of a good sledgehammer), on several grounds:
  o while on a single user machine, it imposes little observable latency
or performance issues, I'm skeptical of the consequences on server
systems, particularly heavily used LTSP servers.  Not only will such
servers end up running many extra processes (and the X traffic transit
extra processes), on such systems, the uncertainties of process
scheduling may cause serious latency issues to users.
  o we need to introduce the notion of users to X in any case, for
multi-user systems, which I believe will become commonplace over the
next 5 years.


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

And an X client using this extension can determine what, exactly?
Clients may be running anywhere, not necessarily even on Linux systems.

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

We'll need to generate such data, and contrast to the existing Xsecurity
mechanism.  It isn't safe to presume that X is at all similar to kernel
system call situations.

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

Can you clarify some?  I'm not yet into the lingo of what is meant by
context strings.

I don't mind major performance hits when policies are reloaded;
presumably regenerating a cache can happen over time.

I would like a system which does not require full reset and application
restart to load new policies, if possible.  If not possible, I'd like to
understand why.

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

Adding onto the end of that structure should be safe.

What is NRES 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.
> 
> 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.

We have the opportunity to put whatever kinds of credentials into the
connection setup.

Hacking the operating system doesn't make sense; you certainly can't
hack VMS, *BSD, HP/UX, Windows to match.

At Ted T'so's suggestion, I've been taking a quick look at SASL as an
authentication framework.

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

Not clear there is a test suite.

Furthermore, it isn't clear anyone actually uses the XSecurity extension
at this date.  It would be reassuring if anyone has an *informed*
opinion of whether there are still users interested in using the
existing extension.  If not, then we're much less concerned about
compatibility, obviously.

We'd like to know if anyone does.

The only known use of it on current platforms is SSH; but here, it was a
complete bust.  The new extensions have no support for it, so the SSH
folks had to add another command line flag just to disable its use, and
I gather current toolkits won't interoperate with it (as it forbids
operations that the toolkits depend on).


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

Yup.  Not very enlightening, the documents I've seen...

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

Well, SASL may provide some help here...
				- Jim