XSELinux and the new devPrivates
Eamon Walsh
ewalsh at tycho.nsa.gov
Thu Apr 29 18:37:18 PDT 2010
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
More information about the xorg-devel
mailing list