From: ewalsh@tycho.nsa.gov (Eamon Walsh)
Date: Tue, 10 Nov 2009 18:55:30 -0500
Subject: [refpolicy] [PATCH] make consolekit_t a confined X client
In-Reply-To: <4AEF0907.1040806@redhat.com>
References: <4AEB72FE.60803@tycho.nsa.gov>
	<1257170929.17520.20.camel@gorn.columbia.tresys.com>
	<4AEF0907.1040806@redhat.com>
Message-ID: <4AF9FD72.1040501@tycho.nsa.gov>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

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.


> I think there should be an interface called xserver_common_app()
> Which just takes the type, no setting up random tmpfs, or random template types.  Too complicated, for any policy writer to understand.
>
>   

I think we should be able to get there.  Just need to work on the tmpfs
thing and maybe have another interface that doesn't call
xserver_object_types_template (it would use an already defined set of X
object types).



-- 

Eamon Walsh 
National Security Agency