From: cpebenito@tresys.com (Christopher J. PeBenito)
Date: Wed, 02 Dec 2009 09:03:15 -0500
Subject: [refpolicy] [PATCH] make consolekit_t a confined X client
In-Reply-To: <4B145F3F.2080400@tycho.nsa.gov>
References: <4AEB72FE.60803@tycho.nsa.gov>
	<1257170929.17520.20.camel@gorn.columbia.tresys.com>
	<4AEF0907.1040806@redhat.com>  <4AF9FD72.1040501@tycho.nsa.gov>
	<1257950793.17482.15.camel@gorn.columbia.tresys.com>
	<4B145F3F.2080400@tycho.nsa.gov>
Message-ID: <1259762596.15456.15.camel@gorn>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

On Mon, 2009-11-30 at 19:11 -0500, Eamon Walsh wrote:
> 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.

I will investigate 3.  If that works, then I'll look at Dan's
xserver_common_x_app() again.

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

Is there more than this patch?  If not, I lost track of the others.

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