XACE performance data, fixed XACE patch

[Bryan Ericson]

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

> Bryan Ericson wrote:
[snip]
> > 
> > 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.

Thanks,
Bryan