Eamon Walsh 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.
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.
I'll look at implementing a dixPropertyLookup function. Do any other
XACE hooks have value-return parameters, would it just be va_arg(ap,
PropertyPtr*)?
What about the idea of an exception list of single-instance root-window
properties?
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.
--
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.
