Currently the root window drawable is labeled s0 which is system low but
it seems like it should be system high (s15:c0.c1023).
As for polyinstantiating properties I've been looking at dix property,
xace and xselinux and thinking about how it could be done. Looking at
property.c it seems like FindProperty would be the logical place to
search for properties based on name, context and probably a list of
singleton root window properties (as Glenn mentions). Currently
FindProperty doesn't use XaceHook and it is unclear whether
XACE_PROPERTY_ACCESS would be the right hook. Also other functions,
ProcGetProperty, don't use FindProperty to find properties.
Regarding the idea of setting the context when a property is written
this would only be feasible when the mode was PropModeReplace. Even if
this were deemed a reasonable approach there'd probably still be a list
of singleton root window properties that writers could not change the
context of.
We really need a solution to the issue of polyinstantiated properties or
there is no way X apps will run in MLS enforcing mode.
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.
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.
--Glenn
Xavier Toth wrote:
Ok that helped the issue with the notification-daemon. Now I'm looking
at some avcs generated while running one of our apps and have some
more questions. I first ran QBrowser at CONFIDENTIAL(s2:c0.c253) then
later ran it at TS(s4:c0.c253). CUT_BUFFER0 and _MOTIF_DRAG_TARGETS
got created at CONFIDENTIAL and then the TS instance of the app tried
to use them, do we need polyinstantiated properties? Or maybe the type
should change on write.
avc: denied { write } for request=X11:ChangeProperty
comm=/opt/jcdx/bin/QBrowser property=CUT_BUFFER0
scontext=swo_u:user_r:user_t:s4:c0.c253
tcontext=swo_u:object_r:clipboard_xproperty_t:s2:c0.c253
tclass=x_property
avc: denied { write } for request=X11:ChangeProperty
comm=/opt/jcdx/bin/QBrowser property=_MOTIF_DRAG_TARGETS
scontext=swo_u:user_r:user_t:s4:c0.c253
tcontext=swo_u:object_r:user_default_xproperty_t:s2:c0.c253
tclass=x_property
Why are the root window drawable and root color map s0?
avc: denied { send } for request=X11:SendEvent
comm=/opt/jcdx/bin/QBrowser resid=76 restype=WINDOW
scontext=swo_u:user_r:user_t:s4:c0.c253
tcontext=system_u:object_r:x_rootwindow_t:s0 tclass=x_drawable
avc: denied { remove_color } for request=X11:FreeColors
comm=/opt/jcdx/bin/QBrowser resid=20 restype=COLORMAP
scontext=swo_u:user_r:user_t:s4:c0.c253
tcontext=system_u:object_r:x_rootcolormap_t:s0 tclass=x_colormap
--
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.
