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

[ewalsh@tycho.nsa.gov (Eamon Walsh)]

On 11/11/2009 09:46 AM, Christopher J. PeBenito wrote:
> On Tue, 2009-11-10 at 18:55 -0500, Eamon Walsh wrote:
>   
>> On 11/02/2009 11:29 AM, Daniel J Walsh wrote:
>>     
>>> On 11/02/2009 09:08 AM, Christopher J. PeBenito wrote:
>>>   
>>>       
>>>> On Fri, 2009-10-30 at 19:13 -0400, Eamon Walsh wrote:
>>>>     
>>>>         
>>>>> Note: I don't know what to put for the third argument to xserver_user_x_domain_template.
>>>>> tmpfs_t?  user_tmpfs_t?  Why does this template have a tmpfs argument anyway?
>>>>>       
>>>>>           
>>>> Its designed for full X apps that use the display for their tmpfs type
>>>> used for the shm.  Does consolekit need a subset of whats in
>>>> xserver_user_x_domain_template?
>>>>     
>>>>         
>> In the case of the consolekit ck-get-x11-server-pid program, it does not
>> create any shared memory segments, so no it does not need the tmpfs
>> argument.
>>
>> The reason the tmpfs argument is there is so the X server can get
>> permission to read the shared memory segment created by the domain.  I
>> wonder if the X server could simply be granted access to all such
>> segments in a blanket typealias rule.  This would eliminate the need for
>> the tmpfs argument.
>>
>> Barring that, I think it might be worthwhile to separate out the tmpfs
>> stuff into a separate interface.  I'll see if I can put something together.
>>     
> As I mentioned earlier, the concept for the interface was for usage on
> full fledged X apps that have windows, etc.  Perhaps we should pause for
> a moment to establish what types of X apps there are?
>
>   


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?




-- 

Eamon Walsh 
National Security Agency

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: ck-avc.txt
Url: http://oss.tresys.com/pipermail/refpolicy/attachments/20091130/9db2ece9/attachment.txt