Re: X avcs

[Glenn Faden <Glenn.Faden@sun.com>]

Eamon Walsh wrote:
> Glenn Faden wrote:
>>
>> 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 ability 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?
The contents of the root window is typically irrelevant. In most modern 
desktops the root window is completely obscured by a desktop window and 
various panel windows. It should not be required to run a screenshot 
applications at system high unless you are trying to dump system high 
pixels. If you allow higher-level windows to overlap lower-level windows 
(as we do), then you must have some kind of censoring logic. In our case 
we blacken any row in which there are any exposed pixels which are not 
dominated by the label of the snapshot application. However, our 
convention of running separately labeled clients in separate workspaces 
permits fullscreen snapshots to be taken at the label of the workspace.
>
>> 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.
>
You're probably right, but you can use our code if you wish.

--Glenn

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.