SE-DBUS policy

SE-DBUS policy

[Christopher J. PeBenito]

Is there any documentation on the SELinux behavior on dbus?  From some
discussion in the IRC channel, the policy templates (which is still
basically the NSA example policy stuff) don't match the code.

The templates creates a type:

type [connector domain prefix]_dbusd_[bus owner prefix]_t;

so if you have staff_r's connection to the system bus, you get
staff_dbusd_system_t.  Then there is a type_change so dbus knows what
label to give the connection:

type_change [domain] [bus owner prefix]_dbusd_t:dbus [connector type];

which results in something like this:

type user_mozilla_dbusd_system_t;
type_change user_mozilla_t system_dbusd_t:dbus user_mozilla_dbusd_system_t;

Then based on the template, I believe the premise was that the dbus
permissions would be between these derived types.  However, in the
policy there are no dbus:send_msg rules for these types (except for the
ones given in the templates), and instead rules are against the real
domains, (e.g. allow NetworkManager_t dhcpd_t:dbus send_msg;).  So I
looked in the dbus code, and I didn't see any calls to
security_compute_relabel().  It looks like this bit of policy is dead,
and the templates need to be revised.

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


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: SE-DBUS policy

[Stephen Smalley]

On Tue, 2007-10-23 at 12:46 +0000, Christopher J. PeBenito wrote:
> Is there any documentation on the SELinux behavior on dbus?  From some
> discussion in the IRC channel, the policy templates (which is still
> basically the NSA example policy stuff) don't match the code.
> 
> The templates creates a type:
> 
> type [connector domain prefix]_dbusd_[bus owner prefix]_t;
> 
> so if you have staff_r's connection to the system bus, you get
> staff_dbusd_system_t.  Then there is a type_change so dbus knows what
> label to give the connection:
> 
> type_change [domain] [bus owner prefix]_dbusd_t:dbus [connector type];
> 
> which results in something like this:
> 
> type user_mozilla_dbusd_system_t;
> type_change user_mozilla_t system_dbusd_t:dbus user_mozilla_dbusd_system_t;
> 
> Then based on the template, I believe the premise was that the dbus
> permissions would be between these derived types.  However, in the
> policy there are no dbus:send_msg rules for these types (except for the
> ones given in the templates), and instead rules are against the real
> domains, (e.g. allow NetworkManager_t dhcpd_t:dbus send_msg;).  So I
> looked in the dbus code, and I didn't see any calls to
> security_compute_relabel().  It looks like this bit of policy is dead,
> and the templates need to be revised.

Hmm...I see a post by Colin Walters back in Oct 2004 to add such logic
to dbusd along with the corresponding policy patches, but no evidence
that the code was ever merged.  I also see at least one other patch from
Colin that added further dbus permissions, again with no evidence that
it was ever merged.

As far as I know, the dbus-daemon man page is the best documentation on
the SELinux behavior in dbus - it has a description of the configuration
for dbus contexts as well as the checks applied by SELinux.  Hopefully
it is still up to date.

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: SE-DBUS policy

[Colin Walters]

Stephen Smalley wrote:
> On Tue, 2007-10-23 at 12:46 +0000, Christopher J. PeBenito wrote:
>   
>> Is there any documentation on the SELinux behavior on dbus?  From some
>> discussion in the IRC channel, the policy templates (which is still
>> basically the NSA example policy stuff) don't match the code.
>>
>> The templates creates a type:
>>
>> type [connector domain prefix]_dbusd_[bus owner prefix]_t;
>>
>> so if you have staff_r's connection to the system bus, you get
>> staff_dbusd_system_t.  Then there is a type_change so dbus knows what
>> label to give the connection:
>>
>> type_change [domain] [bus owner prefix]_dbusd_t:dbus [connector type];
>>
>> which results in something like this:
>>
>> type user_mozilla_dbusd_system_t;
>> type_change user_mozilla_t system_dbusd_t:dbus user_mozilla_dbusd_system_t;
>>
>> Then based on the template, I believe the premise was that the dbus
>> permissions would be between these derived types.  However, in the
>> policy there are no dbus:send_msg rules for these types (except for the
>> ones given in the templates), and instead rules are against the real
>> domains, (e.g. allow NetworkManager_t dhcpd_t:dbus send_msg;).  So I
>> looked in the dbus code, and I didn't see any calls to
>> security_compute_relabel().  It looks like this bit of policy is dead,
>> and the templates need to be revised.
>>     
>
> Hmm...I see a post by Colin Walters back in Oct 2004 to add such logic
> to dbusd along with the corresponding policy patches, but no evidence
> that the code was ever merged.  I also see at least one other patch from
> Colin that added further dbus permissions, again with no evidence that
> it was ever merged.
>
> As far as I know, the dbus-daemon man page is the best documentation on
> the SELinux behavior in dbus - it has a description of the configuration
> for dbus contexts as well as the checks applied by SELinux.  Hopefully
> it is still up to date.
>
>   
I vaguely recall that at the time I was prototyping things out, and 
seeing what interest there was in the patches.  It could probably be 
revived if there was sufficient interest; we should step through the use 
cases for them.  The current :dbus object class is coarse but you can do 
quite a bit with it.

I think you're right though that the policy should probably drop the 
macros until support for it is included in D-BUS and widely distributed.



--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: SE-DBUS policy

[Christopher J. PeBenito]

On Tue, 2007-10-23 at 11:30 -0400, Colin Walters wrote:
> Stephen Smalley wrote:
> > On Tue, 2007-10-23 at 12:46 +0000, Christopher J. PeBenito wrote:
> >   
> >> Is there any documentation on the SELinux behavior on dbus?  From some
> >> discussion in the IRC channel, the policy templates (which is still
> >> basically the NSA example policy stuff) don't match the code.
> >>
> >> The templates creates a type:
> >>
> >> type [connector domain prefix]_dbusd_[bus owner prefix]_t;
> >>
> >> so if you have staff_r's connection to the system bus, you get
> >> staff_dbusd_system_t.  Then there is a type_change so dbus knows what
> >> label to give the connection:
> >>
> >> type_change [domain] [bus owner prefix]_dbusd_t:dbus [connector type];
> >>
> >> which results in something like this:
> >>
> >> type user_mozilla_dbusd_system_t;
> >> type_change user_mozilla_t system_dbusd_t:dbus user_mozilla_dbusd_system_t;
> >>
> >> Then based on the template, I believe the premise was that the dbus
> >> permissions would be between these derived types.  However, in the
> >> policy there are no dbus:send_msg rules for these types (except for the
> >> ones given in the templates), and instead rules are against the real
> >> domains, (e.g. allow NetworkManager_t dhcpd_t:dbus send_msg;).  So I
> >> looked in the dbus code, and I didn't see any calls to
> >> security_compute_relabel().  It looks like this bit of policy is dead,
> >> and the templates need to be revised.
> >>     
> >
> > Hmm...I see a post by Colin Walters back in Oct 2004 to add such logic
> > to dbusd along with the corresponding policy patches, but no evidence
> > that the code was ever merged.  I also see at least one other patch from
> > Colin that added further dbus permissions, again with no evidence that
> > it was ever merged.
> >
> > As far as I know, the dbus-daemon man page is the best documentation on
> > the SELinux behavior in dbus - it has a description of the configuration
> > for dbus contexts as well as the checks applied by SELinux.  Hopefully
> > it is still up to date.
> >
> >   
> I vaguely recall that at the time I was prototyping things out, and 
> seeing what interest there was in the patches.  It could probably be 
> revived if there was sufficient interest; we should step through the use 
> cases for them.  The current :dbus object class is coarse but you can do 
> quite a bit with it.

I think it boils down to if we want to be able to enforce over which bus
the message is sent.  Since the type of the bus is encoded in the types
you could say something like

allow staff_mozilla_dbusd_staff_t staff_dbusd_staff_t:dbus send_msg;

which says staff's mozilla can only send to the user domain over staff's
dbus.  With the direct domain to domain (what we have right now) it says
nothing about which bus the message goes over.

That being said, I'm not sure that it matters which bus a message goes
over.

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


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: SE-DBUS policy

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Christopher J. PeBenito wrote:
> On Tue, 2007-10-23 at 11:30 -0400, Colin Walters wrote:
>> Stephen Smalley wrote:
>>> On Tue, 2007-10-23 at 12:46 +0000, Christopher J. PeBenito wrote:
>>>   
>>>> Is there any documentation on the SELinux behavior on dbus?  From some
>>>> discussion in the IRC channel, the policy templates (which is still
>>>> basically the NSA example policy stuff) don't match the code.
>>>>
>>>> The templates creates a type:
>>>>
>>>> type [connector domain prefix]_dbusd_[bus owner prefix]_t;
>>>>
>>>> so if you have staff_r's connection to the system bus, you get
>>>> staff_dbusd_system_t.  Then there is a type_change so dbus knows what
>>>> label to give the connection:
>>>>
>>>> type_change [domain] [bus owner prefix]_dbusd_t:dbus [connector type];
>>>>
>>>> which results in something like this:
>>>>
>>>> type user_mozilla_dbusd_system_t;
>>>> type_change user_mozilla_t system_dbusd_t:dbus user_mozilla_dbusd_system_t;
>>>>
>>>> Then based on the template, I believe the premise was that the dbus
>>>> permissions would be between these derived types.  However, in the
>>>> policy there are no dbus:send_msg rules for these types (except for the
>>>> ones given in the templates), and instead rules are against the real
>>>> domains, (e.g. allow NetworkManager_t dhcpd_t:dbus send_msg;).  So I
>>>> looked in the dbus code, and I didn't see any calls to
>>>> security_compute_relabel().  It looks like this bit of policy is dead,
>>>> and the templates need to be revised.
>>>>     
>>> Hmm...I see a post by Colin Walters back in Oct 2004 to add such logic
>>> to dbusd along with the corresponding policy patches, but no evidence
>>> that the code was ever merged.  I also see at least one other patch from
>>> Colin that added further dbus permissions, again with no evidence that
>>> it was ever merged.
>>>
>>> As far as I know, the dbus-daemon man page is the best documentation on
>>> the SELinux behavior in dbus - it has a description of the configuration
>>> for dbus contexts as well as the checks applied by SELinux.  Hopefully
>>> it is still up to date.
>>>
>>>   
>> I vaguely recall that at the time I was prototyping things out, and 
>> seeing what interest there was in the patches.  It could probably be 
>> revived if there was sufficient interest; we should step through the use 
>> cases for them.  The current :dbus object class is coarse but you can do 
>> quite a bit with it.
> 
> I think it boils down to if we want to be able to enforce over which bus
> the message is sent.  Since the type of the bus is encoded in the types
> you could say something like
> 
> allow staff_mozilla_dbusd_staff_t staff_dbusd_staff_t:dbus send_msg;
> 
> which says staff's mozilla can only send to the user domain over staff's
> dbus.  With the direct domain to domain (what we have right now) it says
> nothing about which bus the message goes over.
> 
> That being said, I'm not sure that it matters which bus a message goes
> over.
> 



Colin is there any intension of setting context on the types of messages
that can be sent.

As an example:
With the xguest user I want to be able to mount usb sticks.  So I need
to allow xguest_t to dbus_chat with HAL.  I don't want the xguest user
to suspend/hibernate, but that uses dbus_chat also.

So I can not prevent one and allow the other.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFHHl6RrlYvE4MpobMRAnU8AKC0N0i4SdHfifTOYLTV8BuzPUVF5gCcCBFc
8fOfoomxBlSU/ZTINa/cqj0=
=bRxd
-----END PGP SIGNATURE-----

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.