From: ewalsh@tycho.nsa.gov (Eamon Walsh) Date: Mon, 30 Nov 2009 19:11:43 -0500 Subject: [refpolicy] [PATCH] make consolekit_t a confined X client In-Reply-To: <1257950793.17482.15.camel@gorn.columbia.tresys.com> 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> Message-ID: <4B145F3F.2080400@tycho.nsa.gov> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com 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