XSELinux and the new devPrivates

[Eamon Walsh]

On 04/29/2010 05:48 PM, Keith Packard wrote:
> Here are a few comments about how I see the new devPrivates scheme
> working with XSELinux. Note that the current implementation is
> sub-optimal when XSELinux is enabled -- the XSELinux private keys get
> initialized late in the game and end up increasing the size of all of
> the private records with big chunks of wasted space between their
> highest other private index and the XSELinux private index.
>   

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


> The new privates scheme allows for some of the private keys to remain
> 'global', useful in all objects with privates. That's how the old
> private implementation worked, so this provides an obvious replication
> of that functionality.
>
> It's not what XSELinux actually needs though. XSELinux uses privates in:
>
>  client
>  window
>  pixmap
>  gc
>  cursor
>  colormap
>  device
>  extension
>  selection
>  property
>
> It doesn't need privates in
>
>  screen
>  cursor_bits
>  dbe_screen
>  dbe_window
>  damage
>  glyph
>  glyphset
>  picture
>   

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

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


> So, the first obvious optimization is to simply not provide private
> space for 'PRIVATE_ALL' in these objects. Renaming this
> 'PRIVATE_XSELINUX' might be prudent though.
>   

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

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?


> The second optimization should be to sort the PRIVATE_ALL data below
> all of the other private data. That way you'll get the shared
> PRIVATE_ALL fields first in privates with the per-object data stacked on
> top without any gaps. Because we've got pointers to every key, it should
> be easy to adjust the offsets when a PRIVATE_ALL key is registered. It's
> convenient that XSELinux doesn't need a screen private as that is the
> only serious special case in the current privates code.
>   

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.

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


> Finally, the subjectKey is only needed in clients and devices, and in
> each case the XSELinux code knows which object it is dealing with. So,
> creating separate keys for each of those objects would save space in all
> of the other objects.
>   

Agreed.

> With those changes, the XSELinux privates should be more efficient than
> they are today.
>
> However, it seems like someone who can actually run the code should be
> involved in the process. Should I code some stuff up and let others get
> it working? Or just sit around waiting for someone else to submit fixes?
>   

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


-- 

Eamon Walsh 
National Security Agency