XACE performance data, fixed XACE patch

[Bryan Ericson]

Hi,

On Thu, 10 Mar 2005 22:55:56 +0100
Roland Mainz <roland.mainz at nrubsig.org> wrote:

> Bryan Ericson wrote:
> > I've run some performance tests using x11perf on the XACE security
> > framework.  The tests indicate that, in general, XACE does not
> > severely impact server performance.
> [snip]
> > Additionally, the test turned up a bug in the XACE patch involving
> > a
> > few places where "#ifdef XCSECURITY" should have been replaced
> > with
> > "#ifdef XACE".  The following patch corrects the problem, and
> > supersedes the previous XACE patch.  The XSELINUX patch is not
> > affected by the new XACE patch.
> > 
> > http://dgoeddel.home.insightbb.com/xorg-x11-6.8.2.xace.patch2
> 
> Just some thoughts (I just quickly looked over the patch without
> picking-up all details):
> - Does "xauth"'s "generate" command still work (please read
> https://bugs.freedesktop.org/show_bug.cgi?id=2606#c4) ?
> - You can "censor" XGetImage() requests - but what happens if
> someone
> tries to do a XCopyArea()/XCopyPlane() from a trusted window/pixmap
> to
> an untrusted window/pixmap and then calls XGetImage() on the
> untrusted
> version ?

XACE is a framework for adding additional security-related extensions
alongside (or in place of) the current extensions.  The intent is not
to fix, change, or replace existing functionality, so that a user
should see no changes in behavior regardless of whether the XACE patch
has been applied.

When a new extension is created, it "plugs in" to the XACE framework
and notifies the framework of the type of events it's interested in. 
When these events occur, the framework then calls functionality in the
extension that makes a security decision.  The event is allowed to
occur only if all security extensions agree that it's acceptable.

The framework could be used to add the concept of user ID's, as in the
TSOL link you've provided below, and as Jim Gettys has mentioned in
other posts.

That said, yes, "xauth generate" still works.  As for the XGetImage()
question, I don't know the answer. I'll have to check.


> - Some extensions may need extra handling - GLX (where some OpenGL
> extensions may allow copying of window data), Xprint's XpExtension
> (you
> may want to restrict access to single printers (like those which
> sits in
> a unsecure/public area (this wouldn't be the first case that
> confidetial
> data leave the building just because someone selected the wrong
> printer
> =:-))) and others come ad-hoc in my mind. A general accept/reject
> filter
> for extensions may be usefull here, maybe even used together with
> the
> XC-APPGROUP extensions (e.g. untrusted applications then could live
> in
> their own XC-APPGROUP group (think about something like a *BSD
> "jail")
> where they can't disturb applications in other groups)

Interesting ideas.  Thanks.  The XACE patch has been submitted for
public scrutiny, and we're open to comments and suggestions.  I don't
know whether XACE would be the proper place to handle such things like
this, however, since it's intended to simply pass information to and
from various extensions.  Perhaps a sort of SECURITY-XFIXES extension
would be the proper place for this.

> - (This is likely Solaris-only): XReadScreen() needs to be wrapped,
> too

I'll have to take your word for this - we don't currently have the
resources to check Solaris functionality.

> - Just curious: How does XACE compare to extensions such as Xserver
> additions in "Trusted Solaris" (see
> http://docs.sun.com/app/docs/doc/835-8004/6ruu29hk4?q=trusted+solaris+xsun&a=view
> ... maybe Alan Coopersmith has a better link which describes the
> details
> better... :) ?

Please see my comment above.  I can state that we would be interested
to see the a multi-user security implementation for Xorg, however.

> ----
> 
> Bye,
> Roland
> 
> -- 
>   __ .  . __
>  (o.\ \/ /.o) roland.mainz at nrubsig.org
>   \__\/\/__/  MPEG specialist, C&&JAVA&&Sun&&Unix programmer
>   /O /==\ O\  TEL +49 641 7950090
>  (;O/ \/ \O;)

Thanks,
Bryan