Xace MLS selections

[Pat Kane]

Eamon,

Thanks for the detailed description of polyinstantiated selection list,
I have not thought about that idea to solve my requirements.

A problem that I have seen in my experiments is that while the  end-user
is evaluating the selection re-grade a toolkit timeout will occur that will
cancel the selection request.

Another is that if the end-user disallows that selection reguest I need
to violate the protocol spec to keep the clients from getting confused.

Pat
----

On Fri, Dec 17, 2010 at 12:43 PM, Eamon Walsh <ewalsh at tycho.nsa.gov> wrote:
> On 12/17/2010 01:14 AM, Alan Coopersmith wrote:
>> Pat Kane wrote:
>>> Is the current Xace able to deal with MLS selections?
>>>
>>> If so, how does it handle information downgrades that
>>> need to be reviewed by the end-user?
>> Xace alone is not - it's just a framework used to provide hooks
>> that extensions like SELinux & Solaris Xtsol use to provide their
>> functions.   The Solaris Xtsol module does handle MLS selections,
>> with a way to have the desktop provide UI for end-user review,
>> but I don't know off hand how that's implemented.   The code is
>> of course open for you to explore, and the architects of it are
>> available on the security-discuss at opensolaris.org mailing list.
>>
>> I don't know about SELinux off hand, and am fairly sure the
>> XC-Security extension (the simplest of the Xace implementations)
>> does not.
>>
>
> XACE has hooks that allow security modules to polyinstantiate the selection list.   There can be more than one selection named CLIPBOARD, for example, in the linked list of selections.  Normally the server will return the first match from dixLookupSelection.  However that function has an XACE hook that allows a security module to return a different member of the list, or NULL if it wants to hide the existing selection and force a new selection to be created and added.  The SelectionRec structure has a devPrivates field that allows the security module to store the security label in each selection, presumably dependent on the client that owns it and/or the name of the selection.  This is all that XACE does; the specific security extension has to do the rest.
>
> For SELinux, The SELinuxSelection function and its helpers does the job of labeling the selections and choosing the one that will be exposed to each client.  SELinux has a configuration file that is used to map selection names to SELinux contexts and specify whether selections should be polyinstantiated or not (exposed through the selabel_lookup(3) call).  The server part does not handle downgrades and upgrades though, this function is delegated to a clipboard manager that uses SELinux protocol requests.  The ListAllSelections request allows the clipboard manager to see all of the selection instances, including duplicates, and SetSelectionUseContext allows it to change the selection instance that it will use.  It can then pretend to own selections on one MLS level while the real owner is on another MLS level.  When a ConvertSelection request is issued the clipboard manager will receive it, prompt the user or whatever, and then fetch the content from the real owner and forward
> it to the requestor.
>
> There's no reason a clipboard manager has to be used; a security extension in the server could do all the work.  There are a lot of ICCCM quirks that have to be worked around though.  For example, on a typical desktop every time clipboard ownership changes there is a storm of ConvertSelection requests of type TARGET (and what appears to be a GTK equivalent), which can be allowed if you don't mind leaking that information.  Sometimes though you'll get requests for the content itself which can be annoying if you're popping up a dialog every time.  Until recently gedit would ask for the content simply to decide if it should gray out the "Paste" menu item (instead of asking for TARGET).
>
>
>
>
> --
>
> Eamon Walsh
> National Security Agency
>
>
>