XACE performance data, fixed XACE patch

[Roland Mainz]

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

So you only use a simple black&white scheme to either "allow" or
"disallow" access and do not have a way for more fine-grained handling,
right (such as the ability to have a "security manager"[1] client which
then shows a dialog (including window name, application,
uid/gid/projid/label) which asks to "grant", "reject" or "dummy" (for
example XGetImage() may either result in a "BadAccess" X error or simply
returns the window background color (sort of "dummy" response)) the
request) ?

[1]=Inspired by the detail that the NCD X terminals poped-up a dialog
when you wanted to use the XIE (X Imagining Extension) without having a
license for it (e.g. some sort of advertising... =:-)

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

Alternatively it may be nice to get Sun to contribute their work to Xorg
as they already have this stuff working since ~~eight years (e.g. at
least since Trusted Solaris 2.5.1) ...

> That said, yes, "xauth generate" still works.

:)

> As for the XGetImage()
> question, I don't know the answer. I'll have to check.

OK

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

Extending the SECURITY extension may fit better here. IMHO something
like allowing more profiles than "trusted" and "untrusted" (which is
basically supported for the X firewall proxy stuff but not directly by
the SECURITY extensions client side) may cure the biggest complaints of
the quite static model used in the current version of the SECURITY
extension.

[snip]
> > - 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.

Well, Sun has that stuff already working on Trusted Solaris... we only
have to beg for a port to Xorg... :)

----

Bye,
Roland

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