XACE performance data, fixed XACE patch
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
> right (such as the ability to have a "security manager" client
> then shows a dialog (including window name, application,
> uid/gid/projid/label) which asks to "grant", "reject" or "dummy"
> example XGetImage() may either result in a "BadAccess" X error or
> returns the window background color (sort of "dummy" response)) the
> request) ?
> =Inspired by the detail that the NCD X terminals poped-up a
> 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
> the SECURITY extensions client side) may cure the biggest complaints
> the quite static model used in the current version of the SECURITY
Definitely an area that will require research.
> > > - 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
> 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