All of lore.kernel.org
 help / color / mirror / Atom feed
* X in enforcing mode
@ 2008-06-29 18:14 Joe Nall
  2008-06-30 18:18 ` Eamon Walsh
  0 siblings, 1 reply; 2+ messages in thread
From: Joe Nall @ 2008-06-29 18:14 UTC (permalink / raw)
  To: SELinux List

In order to get firefox, evolution and xterm to run under twm with the  
X object manager in enforcing/mls at a single level I had to add the  
following user policy:

         allow $1_t $1_rootwindow_t:x_drawable { get_property getattr  
read override hide send destroy remove_child };
         allow $1_t $1_xserver_t:x_resource write;

Where $1 is user

xinit was started by hand at init 3.

Not being an X guy, I don't really understand what I just allowed.  
Does this make sense?

joe


--
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.

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: X in enforcing mode
  2008-06-29 18:14 X in enforcing mode Joe Nall
@ 2008-06-30 18:18 ` Eamon Walsh
  0 siblings, 0 replies; 2+ messages in thread
From: Eamon Walsh @ 2008-06-30 18:18 UTC (permalink / raw)
  To: Joe Nall; +Cc: SELinux List

Joe Nall wrote:
> In order to get firefox, evolution and xterm to run under twm with the  
> X object manager in enforcing/mls at a single level I had to add the  
> following user policy:
>
>          allow $1_t $1_rootwindow_t:x_drawable { get_property getattr  
> read override hide send destroy remove_child };
>          allow $1_t $1_xserver_t:x_resource write;
>
> Where $1 is user
>
> xinit was started by hand at init 3.
>
> Not being an X guy, I don't really understand what I just allowed.  
> Does this make sense?
>   

I can take a look at it if you send the original AVC's.  I'm assuming 
for the moment that twm is running in $1_t.

At first glance, everything seems normal, although the fact that 
something (hopefully the window manager) is requesting "destroy", 
"hide", and "override" on the root window is kind of odd.  "Read" 
permission should only be granted to the window manager, since it allows 
a screen-shot to be taken.  The x_resource object class is a generic 
fallback for any X object that doesn't have its own object class - I'd 
need to see the AVC to see what's going on there.

The other permissions are normal and safe to grant.  Briefly:

"get_property" allows the app to read properties on the root window.
"getattr" allows the app to query the size of the root window or other 
attributes.
"send" allows the app to send an event to the root window (this is done 
as part of some ICCCM conventions for communicating with the window 
manager).
"remove_child" allows the app to destroy its own windows when it's done.



-- 
Eamon Walsh <ewalsh@tycho.nsa.gov>
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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2008-06-30 18:18 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-06-29 18:14 X in enforcing mode Joe Nall
2008-06-30 18:18 ` Eamon Walsh

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.