XACE and XSELinux patches for Xorg 6.8.2

[Bryan Ericson]

On Wed, 02 Mar 2005 16:58:15 -0500
Jim Gettys <Jim.Gettys at hp.com> wrote:

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

There are patches available for SSH that allow it to use SELinux
functionality.  I don't know how well this works in terms of tunneling
X communications, however.  I do agree that this is not well-suited
for use on heavily-loaded systems.

We would also be interested in the introduction of users to X,
particularly for use as a security component in CMW-type systems.  The
requirements for most CMWs specify that some form of DAC is mandatory,
and this feature would likely fufill that requirement.  Of course,
this would also have much wider applications beyond the CMW world.


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

In the current implementation, an X client has no option on whether or
not use the XSELinux extension - it's used exclusively by the server.
The extension makes security decisions and the server then performs or
rejects the client's request.  Even clients connecting from remote,
non-SELinux machines are subject to the security decisions made by the
XSELinux extension.  In an analogy, if I ssh from my Windows box to an
SELinux machine, the shell I'm granted when I log in is subject to the
security policy of the machine it's running on.


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

We're very interested in performance considerations.  We're on the
lookout for a test suite that utilizes XSecurity that we could run on
XACE vs. non-XACE configurations.  However, as mentioned elsewhere,
there is little public support for the XSecurity extension, and a test
suite has not yet presented itself.  Additionally, the scarcity of
documentation makes the task of creating a new test suite unappealing.

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

Certainly.

A context string contains a process' security information, and every
security decision that involves that process is based the process'
context.

Similarly, the XSELinux extension stores a context string for every X
client. The context is stored for the client for performance reasons -
it would be possible to retrieve the client's context whenever a
security decision is required, but this would incur an unacceptable
performance overhead.

If the policy is modified and reloaded in such a manner that makes
some of the context strings stored by the server invalid, then any
security decision will be rejected outright, which would require
shutting down the server and restarting so that new contexts can be
generated as the X clients reconnect.

That said, it should not be terribly difficult to make it so that the
XSELinux extension is aware of when a new policy is loaded, so that it
can somehow update the contexts of the X clients.  The exact mechanism
would need to be investigated and the operation would have a
performance impact while new contexts for each client are retrieved,
but the system would then not require a reboot.



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

NRES is an index into an array of security contexts.  Each member of
the array corresponds to a type of X resource that is associated with
the X client, such as windows, drawables, colormaps, etc.  These
contexts are used to protect the client's various resources.  The
extension is implemented in this manner to provide fine-grained access
to the client's resources.

For example, if client 1 needs to access client 2's windows, then the
system's security policy can be written to grant this access. 
However, client 2's drawables are still protected from client 1,
because that particular acces was not added to the policy.


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

I'm not terribly familiar with SASL.  I've just looked through the
SASL rfc (2222), and at first glance it seems as though it holds
promise.


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

I'd be interested to know how the CMW community tests their software
if there are no (non-proprietary) test suites.  We will continue to
dig for one...

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

I will continue to investigate as well.

Thank you for your thoughtful replies,
Bryan