Re: SE-DBUS policy

[Daniel J Walsh <dwalsh@redhat.com>]

-----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.