[RFC PATCH] XACE: support for property polyinstantiation

[Eamon Walsh]

Pat Kane wrote:
> Eamon,
>
> Thanks for the update,  could you explain the "polyinstantiation"
> issue a bit more?  What is a typical use case?
>   

The target environment for this is MLS type systems where X clients have 
different levels and should not be able to talk to each other except 
through controlled means.  For properties, the issue was root window 
properties like the cut buffers that are globally writable by 
convention.  When one client touched the cut buffer and then a different 
level client tried to touch it, this was causing permission errors, 
certainly correct but given the default Xlib error handling method this 
was causing problems.  Polyinstantiation for properties allows more than 
one property with the same name to exist so each level can have its own 
set of cut buffers.

With selections it's the same idea.  My first attempt from last March 
was to redirect all ConvertSelection requests to some trusted client.  
But ICCCM cut & paste involves the requestee writing the data to some 
property on the requestor's window, so that solution requires a lot of 
awkwardness to make sure only the trusted client does the writing.

With polyinstantiation of selections there can be multiple instances of 
each selection, so X clients at the same level can cut & paste without 
interference and they won't see what's going on at the other levels.  
There will still need to be a trusted client (clipboard manager) to 
support cut & paste between levels, but this can be done without any 
special server-side logic other than the security module.

At the XACE level, this support is all generic; there are no semantics 
attached to what "polyinstantiation" means.  The XACE changes simply 
allow more than one element with the same name to exist in the list, and 
a way for a security module to return the correct list element if it's 
not the first one with that name.

Hope this explanation helps.


> Thanks for moving the selection code into a separate file,
> I have thought about doing that every time I touch that
> old crufty code.
>
> Pat
> ---
>
>   
>> OK, the scope of this has expanded to include polyinstantiation for
>> selections as well.  The mechanism will be the same: more than one
>> instance allowed in the list of selections; lookup function used for all
>> accesses; calls into XACE which can return the "real" selection
>> structure to use; optimized away when XACE not built.  I've factored the
>> selection code out of dispatch.c into a new file dix/selection.c for
>> better organization.  Will post the patch in a little bit.
>>
>> This supersedes the older redirection work I did on selections,
>> referenced below, which will be backed out.
>> http://lists.freedesktop.org/archives/xorg/2007-March/022720.html
>>
>>
>> --
>> Eamon Walsh <ewalsh at tycho.nsa.gov>
>> National Security Agency
>>
>> _______________________________________________
>> xorg mailing list
>> xorg at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/xorg
>>
>>     
>
>   


-- 
Eamon Walsh <ewalsh at tycho.nsa.gov>
National Security Agency