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.
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.
