Glenn Faden wrote:
Ted X Toth wrote:
Currently the root window drawable is labeled s0 which is system low
but it seems like it should be system high (s15:c0.c1023).
We treat it as system low to make screen snapshots and animations work
properly. It also provides better integrity. Why should it be system high?
I think you want to make a distinction between the root drawable (as a
viewable image) and as a conduit for event notification. In our
implementation the drawable is system low, but the label for sending
events to the root window is essentially system high. Anyone can send an
event to the root window, but these events are only delivered to TCB
clients. The ability to express interest in such events is restricted.
I have to think about this some more, but currently there is no
separation between event destination and drawable in the SELinux model -
they are the same object. The abiliy to read/write the drawable and
send/receive events are separate TE permissions.
The contexts on the root window and root colormap are derived through
type transitions from the context of the X server process. I think the
root window probably should be system-high, because without some kind of
censoring logic, if you can read the contents of a window in X you can
read all of its children as well. Screenshot applications and the
window-manager animations should both be at system-high as well so there
wouldn't be a problem here, no?
We also have a fairly complex policy on labeling the root colormap in
which each color cell is independently labeled. This is an artifact of
the graphics hardware we supported (8bit color maps).
"Requested 84 colors, got 0." Who can forget those days. Anyway, the
original set of X security classes did have a "color" class that was
intended for individual color cells, however I dropped it in my revision
because I decided it would be too much work to fully secure the colormap
implementation given the fact that hardly anything uses indexed-color
mode anymore, and even things that do can just install their own colormaps.
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.
We implemented this before XACE was developed. I think a new hook is
required.
--Glenn
--
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.
