[refpolicy] [PATCH] make consolekit_t a confined X client

[cpebenito@tresys.com (Christopher J. PeBenito)]

On Mon, 2009-11-30 at 19:11 -0500, Eamon Walsh wrote:
> In the context of this discussion (xserver_user_x_domain_template and
> its tmpfs argument), there are two types of X applications:
> 
> 1. Applications that use shared memory to talk to the X server.
> 2. Applications that don't.
> 
> It is reasonable to expect that any GTK+ app, Firefox, pretty much
> anything that opens a graphical window, is going to fall into the
> first
> category.  The shared memory support does provide a speedup for
> transferring large images to X.  This is the common case.
> 
> But there are some few X apps that don't do any drawing and
> ck-get-x11-server-pid is one of those apps.  The only thing
> ck-get-x11-server-pid does is connect to the X server to call
> getpeercon() to find out the PID, as per its name.  (Unfortunately,
> the
> X11 library creates some unnecessary X objects, but this is
> ancillary).
> 
> To write policy for ck-get-x11-server-pid, a tmpfs type is not really
> needed, nor was it apparent to me what tmpfs type to pass to
> xserver_user_x_domain_template.  I used "tmpfs_t" and that compiled
> OK. 
> Part of the problem here is that this is getting run from some random
> consolekit process in system_u, not as part of the user's session (I
> have attached the AVC's).
> 
> So here are the alternatives:
> 
> 1. Keep what we have.
> 2. Split up the interface, making a call that doesn't take the tmpfs
> and
> one that does.
> 3. Use a "This is an X tmpfs type" attribute and give the X server
> blanket access to that attribute instead of passing each tmpfs type to
> the interface.
> 
> I like option 3 the best and option 1 next.  Although I'd like some
> guidance on what to do in this specific consolekit case if "tmpfs_t"
> wasn't the right choice.
> 
> What else is holding up the merge of the patches?

After looking into this further and trying out an implementation of
option 3, I'm leaning towards option 2.  Are there any other examples
like consolekit?  I'd prefer to see another example of these non drawing
X apps before deciding the course of action, if possible.  Also, if
there are any additional denials in addition to the ones you attached
(from the kernel) can you send those too?  Then if we do go with option
2, the appropriate rules can be separated out.

> 
> 
> 
> 
> 
> plain text
> document
> attachment
> (ck-avc.txt)
> 
> (WW) avc:  denied  { query } for request=X11:QueryExtension
> comm=/usr/libexec/ck-get-x11-server-pid extension=BIG-REQUESTS
> scontext=system_u:system_r:consolekit_t:s0-s15:c0.c255
> tcontext=system_u:object_r:xextension_t:s0 tclass=x_extension
> (WW) avc:  denied  { use } for request=BIG-REQUESTS:Enable
> comm=/usr/libexec/ck-get-x11-server-pid extension=BIG-REQUESTS
> scontext=system_u:system_r:consolekit_t:s0-s15:c0.c255
> tcontext=system_u:object_r:xextension_t:s0 tclass=x_extension
> (WW) avc:  denied  { getattr } for request=X11:CreateGC
> comm=/usr/libexec/ck-get-x11-server-pid resid=107 restype=WINDOW
> scontext=system_u:system_r:consolekit_t:s0-s15:c0.c255
> tcontext=system_u:object_r:root_xdrawable_t:s0-s15:c0.c255
> tclass=x_drawable
> (WW) avc:  denied  { create setattr } for request=X11:CreateGC
> comm=/usr/libexec/ck-get-x11-server-pid resid=800000 restype=GC
> scontext=system_u:system_r:consolekit_t:s0-s15:c0.c255
> tcontext=system_u:object_r:consolekit_t:s0 tclass=x_gc
> (WW) avc:  denied  { get_property } for request=X11:GetProperty
> comm=/usr/libexec/ck-get-x11-server-pid resid=107 restype=WINDOW
> scontext=system_u:system_r:consolekit_t:s0-s15:c0.c255
> tcontext=system_u:object_r:root_xdrawable_t:s0-s15:c0.c255
> tclass=x_drawable
> (WW) avc:  denied  { read } for request=X11:GetProperty
> comm=/usr/libexec/ck-get-x11-server-pid property=RESOURCE_MANAGER
> scontext=system_u:system_r:consolekit_t:s0-s15:c0.c255
> tcontext=system_u:object_r:xproperty_t:s0 tclass=x_property
> 
> 
> 

-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150