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 <[email protected]> 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 [email protected] 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 > > > _______________________________________________ [email protected]: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: [email protected]
