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

[dwalsh@redhat.com (Daniel J Walsh)]

On 12/08/2009 08:49 PM, Eamon Walsh wrote:
> On 12/03/2009 10:08 AM, Christopher J. PeBenito wrote:
>> 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.  
> 
> Well, there are a number of X utilities that do not do any drawing. 
> These include:
> 
> xprop - list X properties on a window
> xlsatoms - list X atoms defined in the server
> xlsclients - list connected X clients
> xhost - configure X server host-based allow list
> xrefresh - force redraw of x screen
> 
> The xhost program is a good example of something that could be confined
> in its own domain (to protect the allowed host list).  However these
> programs are typically run by the user during the login session.  So
> they are not really like the consolekit program which is being run from
> outside the session.
> 
> I am positive that I saw X AVC's from something run from
> system_r:dbusd_t.  However these are no longer happening, so either the
> offending program went away, or it was something that was mislabeled.
> 
> 
>> 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.
>>
>>   
> 
> Here are the kernel AVC's from consolekit_t, the two from
> ck-get-x11-server-pid are near the bottom.  It appears as though it's
> getting run from gdm based on the name of the xauthority directory that
> it's using.
> 
> I checked out the ConsoleKit source code and it looks like the whole
> point of this is to figure out what TTY the X server is running on.
> 
> 
In fedora there is a transition from consolekit to udev


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: services_consolekit.patch
Url: http://oss.tresys.com/pipermail/refpolicy/attachments/20091209/75d55d72/attachment.pl