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 <[email protected]>
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 <[email protected]>
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
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 <[email protected]>
> 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 <[email protected]>
>
> 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
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 <[email protected]>
>> 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 <[email protected]>
>>
>> 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.
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
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
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
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
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
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
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
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