XACE performance data, fixed XACE patch

Bryan Ericson bericson at trustedcs.com
Fri Mar 11 09:25:41 PST 2005

On Fri, 11 Mar 2005 16:23:46 +0100
Roland Mainz <roland.mainz at nrubsig.org> wrote:

> Bryan Ericson wrote:
> > 
> > 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... =:-)

That's correct.  The current implementation has no such facility for
bypassing denied security decisions.  The idea of a "security manager"
is an interesting one, although it may annoy some users during a long
string of denied security decisions.  Also, it raises the problem of
validating the security manager, so as to avoid a trojan that simply
passes "grant" back for every request.

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

Definitely an area that will require research.

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

Now THAT would be great!  Perhaps the Xorg community would even be
willing to do the port if Sun would only provide the source code.


More information about the xorg mailing list