selinux January 2008 archive
Main Archive Page > Month Archives  > selinux archives
selinux: Re: X avcs

Re: X avcs

From: Eamon Walsh <ewalsh_at_nospam>
Date: Thu Jan 10 2008 - 21:14:12 GMT
To: Glenn Faden <>

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 <> National Security Agency -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to with the words "unsubscribe selinux" without quotes as the message.