XSELinux and the new devPrivates

[Keith Packard]

On Thu, 29 Apr 2010 21:37:18 -0400, Eamon Walsh <ewalsh at tycho.nsa.gov> wrote:

> Our mails crossed!  I sent a lengthy reply to the original post.

Perfect!

> SELinux does use the picture and glyphset privates.  Any resource type
> with a devPrivates field and a registered offset (returned by
> dixLookupPrivateOffset) gets used in the resource lookup security hook
> (that gets called from dixLookupResource).

That's fine -- the current implementation sticks a private everywhere
for PRIVATE_ALL just like the existing code. But, with the new code
actually allocating all of the privates, it seems prudent to avoid
sticking XSELinux stuff in objects that just don't need them.

> I'd like any resource or object that can be named from client-space to
> have a devPrivates field and a security label.

Yup. I wish we could stick this in the resource database, but I don't
think it's workable.

> I guess, although hardcoding that set of object types into the core
> server doesn't seem ideal.

I'm trying not to write code we don't actually need, although the API
would make it easy to add this. Just add an API to register a new
private type and make the existing array resizeable.

> Maybe there could be a way to register a key and then "add" new object
> types to it, causing the offsets to be recomputed to make it work?

No offsets would need recomputing; the only fixed part of the
implementation is the array of pointers to lists of private keys.

> I think this is the big win.  I didn't think it was possible, but if you
> can fiddle with the offsets to achieve this without affecting the caller
> I'm all for it.  In my other mail I mentioned something about setting
> aside space at configure time.

We've got pointers to every key in the system, walking them and updating
them will be easy.

> I still worry about stray objects getting created early in the
> initialization sequence before everything has had a chance to
> register.

The code has big 'assert's all over it that will catch any mistakes
here; Tiago Vignetti already found one related to colormaps on multiple
screens. I've fixed that by getting the associated key registered
earlier, but colormaps may come back to haunt us again as the default
colormap is created during screen initialization.

I suspect I'll need a kludge for the default colormap; it may just be
that I need to go and find it and reallocate it on the fly.

> I will test as needed and change the SELinux code as required.

Would you like me to try and rework the PRIVATE_ALL stuff to move them
to the start of the list? With that change, I think the remaining
suggestions were entirely within the XSELinux implementation.

-- 
keith.packard at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg-devel/attachments/20100429/eae57a81/attachment.pgp>