* [refpolicy] [PATCH] make consolekit_t a confined X client
@ 2009-10-30 23:13 Eamon Walsh
2009-11-02 14:08 ` Christopher J. PeBenito
0 siblings, 1 reply; 11+ messages in thread
From: Eamon Walsh @ 2009-10-30 23:13 UTC (permalink / raw)
To: refpolicy
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?
commit fa343fbf30f96528e06a1b487dfef5e808f3b68b
Author: Eamon Walsh <ewalsh@tycho.nsa.gov>
Date: Fri Oct 30 18:47:17 2009 -0400
Make consolekit_t a confined X user.
The program /usr/libexec/ck-get-x11-server-pid connects to the
X server after a user login. The program itself doesn't do
anything except call getpeercred(), however Xlib helpfully
creates some objects and reads properties in XOpenDisplay().
TODO: Fix consolekit to use libxcb instead...
Signed-off-by: Eamon Walsh <ewalsh@tycho.nsa.gov>
diff --git a/policy/modules/services/consolekit.te b/policy/modules/services/consolekit.te
index 1ead55d..ba53a09 100644
--- a/policy/modules/services/consolekit.te
+++ b/policy/modules/services/consolekit.te
@@ -108,6 +108,7 @@ optional_policy(`
optional_policy(`
xserver_read_xdm_pid(consolekit_t)
xserver_read_user_xauth(consolekit_t)
+ xserver_user_x_domain_template(consolekit, consolekit_t, tmpfs_t)
corenet_tcp_connect_xserver_port(consolekit_t)
')
--
Eamon Walsh
National Security Agency
^ permalink raw reply related [flat|nested] 11+ messages in thread* [refpolicy] [PATCH] make consolekit_t a confined X client 2009-10-30 23:13 [refpolicy] [PATCH] make consolekit_t a confined X client Eamon Walsh @ 2009-11-02 14:08 ` Christopher J. PeBenito 2009-11-02 16:29 ` Daniel J Walsh 0 siblings, 1 reply; 11+ messages in thread From: Christopher J. PeBenito @ 2009-11-02 14:08 UTC (permalink / raw) To: refpolicy 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? > commit fa343fbf30f96528e06a1b487dfef5e808f3b68b > Author: Eamon Walsh <ewalsh@tycho.nsa.gov> > Date: Fri Oct 30 18:47:17 2009 -0400 > > Make consolekit_t a confined X user. > > The program /usr/libexec/ck-get-x11-server-pid connects to the > X server after a user login. The program itself doesn't do > anything except call getpeercred(), however Xlib helpfully > creates some objects and reads properties in XOpenDisplay(). > > TODO: Fix consolekit to use libxcb instead... > > Signed-off-by: Eamon Walsh <ewalsh@tycho.nsa.gov> > > diff --git a/policy/modules/services/consolekit.te b/policy/modules/services/consolekit.te > index 1ead55d..ba53a09 100644 > --- a/policy/modules/services/consolekit.te > +++ b/policy/modules/services/consolekit.te > @@ -108,6 +108,7 @@ optional_policy(` > optional_policy(` > xserver_read_xdm_pid(consolekit_t) > xserver_read_user_xauth(consolekit_t) > + xserver_user_x_domain_template(consolekit, consolekit_t, tmpfs_t) > corenet_tcp_connect_xserver_port(consolekit_t) > ') > > > > -- Chris PeBenito Tresys Technology, LLC (410) 290-1411 x150 ^ permalink raw reply [flat|nested] 11+ messages in thread
* [refpolicy] [PATCH] make consolekit_t a confined X client 2009-11-02 14:08 ` Christopher J. PeBenito @ 2009-11-02 16:29 ` Daniel J Walsh 2009-11-10 23:55 ` Eamon Walsh 0 siblings, 1 reply; 11+ messages in thread From: Daniel J Walsh @ 2009-11-02 16:29 UTC (permalink / raw) To: refpolicy 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? > >> commit fa343fbf30f96528e06a1b487dfef5e808f3b68b >> Author: Eamon Walsh <ewalsh@tycho.nsa.gov> >> Date: Fri Oct 30 18:47:17 2009 -0400 >> >> Make consolekit_t a confined X user. >> >> The program /usr/libexec/ck-get-x11-server-pid connects to the >> X server after a user login. The program itself doesn't do >> anything except call getpeercred(), however Xlib helpfully >> creates some objects and reads properties in XOpenDisplay(). >> >> TODO: Fix consolekit to use libxcb instead... >> >> Signed-off-by: Eamon Walsh <ewalsh@tycho.nsa.gov> >> >> diff --git a/policy/modules/services/consolekit.te b/policy/modules/services/consolekit.te >> index 1ead55d..ba53a09 100644 >> --- a/policy/modules/services/consolekit.te >> +++ b/policy/modules/services/consolekit.te >> @@ -108,6 +108,7 @@ optional_policy(` >> optional_policy(` >> xserver_read_xdm_pid(consolekit_t) >> xserver_read_user_xauth(consolekit_t) >> + xserver_user_x_domain_template(consolekit, consolekit_t, tmpfs_t) >> corenet_tcp_connect_xserver_port(consolekit_t) >> ') >> >> >> >> > > 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. ^ permalink raw reply [flat|nested] 11+ messages in thread
* [refpolicy] [PATCH] make consolekit_t a confined X client 2009-11-02 16:29 ` Daniel J Walsh @ 2009-11-10 23:55 ` Eamon Walsh 2009-11-11 14:46 ` Christopher J. PeBenito 0 siblings, 1 reply; 11+ messages in thread From: Eamon Walsh @ 2009-11-10 23:55 UTC (permalink / raw) To: refpolicy 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* [refpolicy] [PATCH] make consolekit_t a confined X client 2009-11-10 23:55 ` Eamon Walsh @ 2009-11-11 14:46 ` Christopher J. PeBenito 2009-12-01 0:11 ` Eamon Walsh 0 siblings, 1 reply; 11+ messages in thread From: Christopher J. PeBenito @ 2009-11-11 14:46 UTC (permalink / raw) To: refpolicy 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? -- Chris PeBenito Tresys Technology, LLC (410) 290-1411 x150 ^ permalink raw reply [flat|nested] 11+ messages in thread
* [refpolicy] [PATCH] make consolekit_t a confined X client 2009-11-11 14:46 ` Christopher J. PeBenito @ 2009-12-01 0:11 ` Eamon Walsh 2009-12-02 14:03 ` Christopher J. PeBenito 2009-12-03 15:08 ` Christopher J. PeBenito 0 siblings, 2 replies; 11+ messages in thread From: Eamon Walsh @ 2009-12-01 0:11 UTC (permalink / raw) To: refpolicy 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* [refpolicy] [PATCH] make consolekit_t a confined X client 2009-12-01 0:11 ` Eamon Walsh @ 2009-12-02 14:03 ` Christopher J. PeBenito 2009-12-03 15:08 ` Christopher J. PeBenito 1 sibling, 0 replies; 11+ messages in thread From: Christopher J. PeBenito @ 2009-12-02 14:03 UTC (permalink / raw) To: refpolicy 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* [refpolicy] [PATCH] make consolekit_t a confined X client 2009-12-01 0:11 ` Eamon Walsh 2009-12-02 14:03 ` Christopher J. PeBenito @ 2009-12-03 15:08 ` Christopher J. PeBenito 2009-12-03 15:56 ` Dominick Grift 2009-12-09 1:49 ` Eamon Walsh 1 sibling, 2 replies; 11+ messages in thread From: Christopher J. PeBenito @ 2009-12-03 15:08 UTC (permalink / raw) To: refpolicy On Mon, 2009-11-30 at 19:11 -0500, Eamon Walsh wrote: > 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? After looking into this further and trying out an implementation of option 3, I'm leaning towards option 2. Are there any other examples like consolekit? I'd prefer to see another example of these non drawing X apps before deciding the course of action, if possible. Also, if there are any additional denials in addition to the ones you attached (from the kernel) can you send those too? Then if we do go with option 2, the appropriate rules can be separated out. > > > > > > plain text > document > attachment > (ck-avc.txt) > > (WW) avc: denied { query } for request=X11:QueryExtension > comm=/usr/libexec/ck-get-x11-server-pid extension=BIG-REQUESTS > scontext=system_u:system_r:consolekit_t:s0-s15:c0.c255 > tcontext=system_u:object_r:xextension_t:s0 tclass=x_extension > (WW) avc: denied { use } for request=BIG-REQUESTS:Enable > comm=/usr/libexec/ck-get-x11-server-pid extension=BIG-REQUESTS > scontext=system_u:system_r:consolekit_t:s0-s15:c0.c255 > tcontext=system_u:object_r:xextension_t:s0 tclass=x_extension > (WW) avc: denied { getattr } for request=X11:CreateGC > comm=/usr/libexec/ck-get-x11-server-pid resid=107 restype=WINDOW > scontext=system_u:system_r:consolekit_t:s0-s15:c0.c255 > tcontext=system_u:object_r:root_xdrawable_t:s0-s15:c0.c255 > tclass=x_drawable > (WW) avc: denied { create setattr } for request=X11:CreateGC > comm=/usr/libexec/ck-get-x11-server-pid resid=800000 restype=GC > scontext=system_u:system_r:consolekit_t:s0-s15:c0.c255 > tcontext=system_u:object_r:consolekit_t:s0 tclass=x_gc > (WW) avc: denied { get_property } for request=X11:GetProperty > comm=/usr/libexec/ck-get-x11-server-pid resid=107 restype=WINDOW > scontext=system_u:system_r:consolekit_t:s0-s15:c0.c255 > tcontext=system_u:object_r:root_xdrawable_t:s0-s15:c0.c255 > tclass=x_drawable > (WW) avc: denied { read } for request=X11:GetProperty > comm=/usr/libexec/ck-get-x11-server-pid property=RESOURCE_MANAGER > scontext=system_u:system_r:consolekit_t:s0-s15:c0.c255 > tcontext=system_u:object_r:xproperty_t:s0 tclass=x_property > > > -- Chris PeBenito Tresys Technology, LLC (410) 290-1411 x150 ^ permalink raw reply [flat|nested] 11+ messages in thread
* [refpolicy] [PATCH] make consolekit_t a confined X client 2009-12-03 15:08 ` Christopher J. PeBenito @ 2009-12-03 15:56 ` Dominick Grift 2009-12-09 1:49 ` Eamon Walsh 1 sibling, 0 replies; 11+ messages in thread From: Dominick Grift @ 2009-12-03 15:56 UTC (permalink / raw) To: refpolicy On Thu, Dec 03, 2009 at 10:08:32AM -0500, Christopher J. PeBenito wrote: > On Mon, 2009-11-30 at 19:11 -0500, Eamon Walsh wrote: > > 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? > > After looking into this further and trying out an implementation of > option 3, I'm leaning towards option 2. Are there any other examples > like consolekit? I'd prefer to see another example of these non drawing > X apps before deciding the course of action, if possible. Also, if I think seahorse-daemon may have similar properties, but not quite sure. I use to have a xace enabled policy for it but i deleted it. I do still have it without the XACE part of the policy. > there are any additional denials in addition to the ones you attached > (from the kernel) can you send those too? Then if we do go with option > 2, the appropriate rules can be separated out. > > > > > > > > > > > > > plain text > > document > > attachment > > (ck-avc.txt) > > > > (WW) avc: denied { query } for request=X11:QueryExtension > > comm=/usr/libexec/ck-get-x11-server-pid extension=BIG-REQUESTS > > scontext=system_u:system_r:consolekit_t:s0-s15:c0.c255 > > tcontext=system_u:object_r:xextension_t:s0 tclass=x_extension > > (WW) avc: denied { use } for request=BIG-REQUESTS:Enable > > comm=/usr/libexec/ck-get-x11-server-pid extension=BIG-REQUESTS > > scontext=system_u:system_r:consolekit_t:s0-s15:c0.c255 > > tcontext=system_u:object_r:xextension_t:s0 tclass=x_extension > > (WW) avc: denied { getattr } for request=X11:CreateGC > > comm=/usr/libexec/ck-get-x11-server-pid resid=107 restype=WINDOW > > scontext=system_u:system_r:consolekit_t:s0-s15:c0.c255 > > tcontext=system_u:object_r:root_xdrawable_t:s0-s15:c0.c255 > > tclass=x_drawable > > (WW) avc: denied { create setattr } for request=X11:CreateGC > > comm=/usr/libexec/ck-get-x11-server-pid resid=800000 restype=GC > > scontext=system_u:system_r:consolekit_t:s0-s15:c0.c255 > > tcontext=system_u:object_r:consolekit_t:s0 tclass=x_gc > > (WW) avc: denied { get_property } for request=X11:GetProperty > > comm=/usr/libexec/ck-get-x11-server-pid resid=107 restype=WINDOW > > scontext=system_u:system_r:consolekit_t:s0-s15:c0.c255 > > tcontext=system_u:object_r:root_xdrawable_t:s0-s15:c0.c255 > > tclass=x_drawable > > (WW) avc: denied { read } for request=X11:GetProperty > > comm=/usr/libexec/ck-get-x11-server-pid property=RESOURCE_MANAGER > > scontext=system_u:system_r:consolekit_t:s0-s15:c0.c255 > > tcontext=system_u:object_r:xproperty_t:s0 tclass=x_property > > > > > > > > -- > Chris PeBenito > Tresys Technology, LLC > (410) 290-1411 x150 > > _______________________________________________ > refpolicy mailing list > refpolicy at oss.tresys.com > http://oss.tresys.com/mailman/listinfo/refpolicy -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20091203/5303c2dd/attachment.bin ^ permalink raw reply [flat|nested] 11+ messages in thread
* [refpolicy] [PATCH] make consolekit_t a confined X client 2009-12-03 15:08 ` Christopher J. PeBenito 2009-12-03 15:56 ` Dominick Grift @ 2009-12-09 1:49 ` Eamon Walsh 2009-12-09 18:25 ` Daniel J Walsh 1 sibling, 1 reply; 11+ messages in thread From: Eamon Walsh @ 2009-12-09 1:49 UTC (permalink / raw) To: refpolicy On 12/03/2009 10:08 AM, Christopher J. PeBenito wrote: > On Mon, 2009-11-30 at 19:11 -0500, Eamon Walsh wrote: > >> 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? >> > After looking into this further and trying out an implementation of > option 3, I'm leaning towards option 2. Are there any other examples > like consolekit? I'd prefer to see another example of these non drawing > X apps before deciding the course of action, if possible. Well, there are a number of X utilities that do not do any drawing. These include: xprop - list X properties on a window xlsatoms - list X atoms defined in the server xlsclients - list connected X clients xhost - configure X server host-based allow list xrefresh - force redraw of x screen The xhost program is a good example of something that could be confined in its own domain (to protect the allowed host list). However these programs are typically run by the user during the login session. So they are not really like the consolekit program which is being run from outside the session. I am positive that I saw X AVC's from something run from system_r:dbusd_t. However these are no longer happening, so either the offending program went away, or it was something that was mislabeled. > Also, if > there are any additional denials in addition to the ones you attached > (from the kernel) can you send those too? Then if we do go with option > 2, the appropriate rules can be separated out. > > Here are the kernel AVC's from consolekit_t, the two from ck-get-x11-server-pid are near the bottom. It appears as though it's getting run from gdm based on the name of the xauthority directory that it's using. I checked out the ConsoleKit source code and it looks like the whole point of this is to figure out what TTY the X server is running on. -- Eamon Walsh National Security Agency -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: avcs.txt Url: http://oss.tresys.com/pipermail/refpolicy/attachments/20091208/6d64c0ea/attachment.txt ^ permalink raw reply [flat|nested] 11+ messages in thread
* [refpolicy] [PATCH] make consolekit_t a confined X client 2009-12-09 1:49 ` Eamon Walsh @ 2009-12-09 18:25 ` Daniel J Walsh 0 siblings, 0 replies; 11+ messages in thread From: Daniel J Walsh @ 2009-12-09 18:25 UTC (permalink / raw) To: refpolicy On 12/08/2009 08:49 PM, Eamon Walsh wrote: > On 12/03/2009 10:08 AM, Christopher J. PeBenito wrote: >> On Mon, 2009-11-30 at 19:11 -0500, Eamon Walsh wrote: >> >>> 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? >>> >> After looking into this further and trying out an implementation of >> option 3, I'm leaning towards option 2. Are there any other examples >> like consolekit? I'd prefer to see another example of these non drawing >> X apps before deciding the course of action, if possible. > > Well, there are a number of X utilities that do not do any drawing. > These include: > > xprop - list X properties on a window > xlsatoms - list X atoms defined in the server > xlsclients - list connected X clients > xhost - configure X server host-based allow list > xrefresh - force redraw of x screen > > The xhost program is a good example of something that could be confined > in its own domain (to protect the allowed host list). However these > programs are typically run by the user during the login session. So > they are not really like the consolekit program which is being run from > outside the session. > > I am positive that I saw X AVC's from something run from > system_r:dbusd_t. However these are no longer happening, so either the > offending program went away, or it was something that was mislabeled. > > >> Also, if >> there are any additional denials in addition to the ones you attached >> (from the kernel) can you send those too? Then if we do go with option >> 2, the appropriate rules can be separated out. >> >> > > Here are the kernel AVC's from consolekit_t, the two from > ck-get-x11-server-pid are near the bottom. It appears as though it's > getting run from gdm based on the name of the xauthority directory that > it's using. > > I checked out the ConsoleKit source code and it looks like the whole > point of this is to figure out what TTY the X server is running on. > > In fedora there is a transition from consolekit to udev -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: services_consolekit.patch Url: http://oss.tresys.com/pipermail/refpolicy/attachments/20091209/75d55d72/attachment.pl ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2009-12-09 18:25 UTC | newest] Thread overview: 11+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2009-10-30 23:13 [refpolicy] [PATCH] make consolekit_t a confined X client Eamon Walsh 2009-11-02 14:08 ` Christopher J. PeBenito 2009-11-02 16:29 ` Daniel J Walsh 2009-11-10 23:55 ` Eamon Walsh 2009-11-11 14:46 ` Christopher J. PeBenito 2009-12-01 0:11 ` Eamon Walsh 2009-12-02 14:03 ` Christopher J. PeBenito 2009-12-03 15:08 ` Christopher J. PeBenito 2009-12-03 15:56 ` Dominick Grift 2009-12-09 1:49 ` Eamon Walsh 2009-12-09 18:25 ` Daniel J Walsh
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.