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. _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
