[refpolicy] [PATCH] make consolekit_t a confined X client
Christopher J. PeBenito
cpebenito at tresys.com
Wed Dec 2 08:03:15 CST 2009
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
> 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.
Tresys Technology, LLC
(410) 290-1411 x150
More information about the refpolicy