[RFC PATCH] XACE: support for property polyinstantiation
Eamon Walsh
ewalsh at tycho.nsa.gov
Tue Feb 12 15:09:57 PST 2008
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
More information about the xorg
mailing list