XACE and XSELinux patches for Xorg 6.8.2 (Resources).

[Bryan Ericson]

On Thu, 03 Mar 2005 14:29:04 -0500
Jim Gettys <Jim.Gettys at hp.com> wrote:

> On Thu, 2005-03-03 at 10:40 -0600, Bryan Ericson wrote:
> 
> > > > Unfortunately, one of the consequences of the XACE framework
> > > > is
> > > > that
> > > > it requires the ClientRec structure to be modified.  In the
> > > > current
> > > > implementation, this is unavoidable.
> > > > 
> > > 
> > > Adding onto the end of that structure should be safe.
> > > 
> > > What is NRES above?
> > 
> > NRES is an index into an array of security contexts.  Each member
> > of
> > the array corresponds to a type of X resource that is associated
> > with
> > the X client, such as windows, drawables, colormaps, etc.  These
> > contexts are used to protect the client's various resources.  The
> > extension is implemented in this manner to provide fine-grained
> > access
> > to the client's resources.
> > 
> > For example, if client 1 needs to access client 2's windows, then
> > the
> > system's security policy can be written to grant this access. 
> > However, client 2's drawables are still protected from client 1,
> > because that particular acces was not added to the policy.
> > 
> 
> Extensions may add new resource types.  Having an static array that
> is
> sized by the number of different resource types isn't going to hack
> it.
> I hate fixed limits on things: no matter what choice you make, it is
> usually wrong.
> 
> For example, the Render extension and XFixes both introduce new
> resource
> types (e.g. Picture and Region).
> 
> So this implementation is brittle, and should be fixed; I think a
> pointer to an array, which might be dynamically re-sized when
> extensions
> create new resource types, would be a pretty straight forward fix.
> 			- Jim
> 

I agree completely with your comments about hard-coded
information.

Your fix sounds good. However, one thing that will need to be
considered is that a new context string will need to be created for
the new resource type.  That resource type will additionally need to
be made known to the security policy, so that accurate security
decisions can be made regarding it.  This brings up the problem that
the policy is static, and cannot be amended at runtime, so the system
administrator must either be skilled enough to write new policy based
on the extensions that will be run by the X server, or the policy
shipped by the distributor must account for every possible resource
that an extension could create.

As you can see, this potentially can become a quagmire in terms of
maintainability.  We've presented the XSELinux extension in its
current form to the community in hopes that these issues can be
considered by a knowledgable, skilled audience, and that a consensus
can be reached on the best path on which to proceed.

Thanks,
Bryan