[Dev] Cynara + DBUS

Patrick Ohly patrick.ohly at intel.com
Thu Apr 24 09:25:43 GMT 2014


On Thu, 2014-04-17 at 15:32 +0200, José Bollo wrote:
> I just documented the setting of smack in DBUS.
> 
> https://wiki.tizen.org/wiki/Security/Smack_setting_of_DBUS
> 
> Best regards and thanks to Brian and Patrick who helped.

I'm not sure whether asking dumb questions counts as helping, but if it
does, then here are some more ;-}

First, one (to me) interesting observation: the dbus-daemon manual says
that "if a connection owns services A, B, C, and sending to A is denied,
sending to B or C will not work either." This is worth keeping in mind,
because it affects the ability of processes to host multiple different
independent services. It's also not very intuitive and thus may cause
surprises. If splitting services into different processes is not an
option, then creating independent D-Bus connections for each service may
be a viable alternative.

Now about the bluetooth.conf: what is the default, deny or allow? If it
is deny, then explicitly listing "own" and the various send operations
for all interfaces makes sense, because without them, sending messages
would be denied. But isn't the <policy smack="User"> element redundant
then, because sending would be denied anyway? If the default is allow,
then the <allow> elements seem redundant.

Finally, about SMACK rules enabling or disabling D-Bus allow/deny rules:
I agree, this requires further explanation. Brian, Casey, can you
comment on the note that José added to the Wiki page?

Wouldn't it be simpler to enable a rule just based on subject label S
(from the current connection) and object label O (from the policy
attribute)? If they are the same, then enable the entire policy element.

Hmm, okay, I think I see how that doesn't scale: we would need to add
D-Bus policies for all labels. When leveraging the SMACK rules, we can
keep D-Bus policies fixed and only add SMACK rules when adding labels.

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.





More information about the Dev mailing list