On Jan 10, 2008 2:27 PM, Eamon Walsh <ewalsh@xxxxxxxxxxxxx> wrote: > Glenn Faden wrote: > > This is my first posting to this alias, so let me start by introducing > > myself. I'm a Distinguished Engineer in the Solaris security > > organization, and I'm the original architect for Sun's multilevel X11 > > server. I have worked on this problem since 1990, and have designed > > three multilevel desktops (Open Look, CDE, and GNOME) > > > > One of the biggest challenges in adding fine-grained policy to the X11 > > server is to make the policy transparent to existing X11 clients. > > Probably the most critical design decision we made was with respect to > > root window resources. By default, all root window properties are > > polyinstantiated by both label and uid. For SELinux, the equivalent > > policy would be polyinstantiation by security context (not just MLS > > label). An exception list of single-instance root-window properties is > > enumerated in a policy file. > > We have found that the list of exceptions is much smaller than the list > > that should be polyinstantiated. > > > > Hello. I am not opposed to the idea of polyinstantiated properties. > Although our approach has always been to attempt to fix applications to > work within the secure environment first, it looks like this is a case > where polyinstantiated is needed. > > My first thought on the implementation is that a value-return parameter > could be added to the PROPERTY_ACCESS hook so that security modules can > return the actual PropertyPtr object they wish to be used. The > FindProperty function would then have to be upgraded to a general lookup > function similar to dixLookupResource(), dixLookupDrawable(), etc. and > the property code would have to be refactored to use it everywhere when > looking up a property. The semantics of the various property requests, > in particular RotateProperties, might make this a little more difficult. > Yep, rotate, list, anything that traverses the property list, is a problem. It seems like it would be better to have a property list per context. How about a dixLookupProperties function on window that would return a linked list (PropertyPtr) of properties that it gets from an xace hook call? > SELinux has a security_compute_member() interface that is intended to > return the security context of the appropriate object for use, and this > can be used to determine which object to return. > > > With respect to the root window drawable, it is protected at the lowest > > label, so it is never modified. Applications like Nautilus are > > polyinstantiated, too, and render their own background windows. > > > > Our implementation is all open-sourced using the Xorg license. A summary > > of the X11 security policy implemented by Solaris Trusted Extensions is > > described in Chapter 6 of the Developer's Guide, > > http://docs.sun.com/app/docs/doc/819-0869/6n391u3ru?a=view > > > > The configuration file for the polyinstantiation policy is described in > > the TrustedExtensionsPolicy man page, > > http://docs.sun.com/app/docs/doc/819-7307/trustedextensionspolicy-4?a=view > > > > The source code which implements this policy can be viewed in the > > OpenSolaris browser using this link: > > http://src.opensolaris.org/source/xref/fox/fox-gate/XW_NV/open-src/xserver/xorg/sun-src/tsol/ > > > > The hooks to the XACE extension layer (also used by SELinux) are in the > > file tsolCompat.c, which can be viewed here: > > http://src.opensolaris.org/source/xref/fox/fox-gate/XW_NV/open-src/xserver/xorg/sun-src/Xext/tsolCompat.c > > > > Although Trusted Extensions and SELinux have significant differences > > with respect to their security models, both systems attempt to implement > > MAC policy in a manner that is transparent to applications. This should > > apply to the desktop, as well. In general, the user experience running > > GNOME on Solaris (with or without Trusted Extensions) or on Linux (with > > or without SELinux) should be almost identical. So the underlying > > policies enforced by the X11 server should follow the same general > > principles. > > > > Our long-term goal is to make applications aware of and responsive to > the security environment, particularly applications that could > themselves be multi-level such as e-mail, web, office. > > -- > > Eamon Walsh <ewalsh@xxxxxxxxxxxxx> > National Security Agency > > -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with the words "unsubscribe selinux" without quotes as the message.
