On Thu, 2014-11-13 at 17:19 +0100, Jacek Bukarewicz wrote: > On 11/12/2014 05:11 PM, Patrick Ohly wrote: > > A "ls -l /usr/bin" can access the directory, but then getting further > > information about its entries is hit-and-miss. What is the correct label > > for files there? I believe it should be _. The ones that are > > inaccessible have something else: > > > > (snip) > Manifest for dbus packages is missing so files inherit smack label of > the installer process. This problem also applies to 1.6.x branch. I'll > try to fix it. Thanks for noticing it.
Odd, I thought that this had been sorted out long ago. Looks like I still need to do the same for SyncEvolution, too. > > With all of that in place I would have expected that running > > dbus-monitor as User continues to work as before, but it doesn't. Is a > > blanket "<check privilege="http://tizen.org/privilege/user"/>" rule > > supported? > > Constructs like <check privilege="..." /> are not supported just like it > is not possible to use <allow /> or <deny /> rules that would grant > access to everything. > One has to specify type of rule by using attributes: > send - send_destination, send_member, send_interface and others > receive - receive_sender, receive_interface, receive_member and others > own - own, own_prefix attributes So instead of just one rule, three different ones will be needed. I suspected that much ;-} > Please note that for <allow> and <deny> it's possible to restrict > connection to the bus per uid/gid: > <allow user="user name or uid" /> > <allow group="group_name" /> I don't think we need that for the purpose of securing API access. Access to the user session bus is already limited to processes of one user via the Unix permissions of the socket. > > Jacek, I'd prefer to leave it to you to figure out the default Cynara > > and D-Bus configs. The goal is to have a default deny in place that only > > affects non-privileged apps. Once that works, service developers can > > think about what rules they need to add to grant access also to > > non-privileged apps. > > > Yes, I'll try to figure it out. > > One solution would be to use per-user rules > <policy user="root" > > <allow ...> <!-- allow methods required by privileged > service --> > .... > </policy> This should already mostly be in place for the system bus. It won't help for normal operation of the user session bus, because typically only processes of one user will connect to it. > I don't think all services will run as root or any well-known user > though. The ones running in user session probably will run with the same > uid as unprivileged apps. Exactly. > However, their smack label will probably be well-known Not just "probably" - definitely! Processes running with the "User" label are considered fully trusted and allowed to do everything that the user is allowed to do. Currently all apps run that way. We need to keep them running unimpeded when adding security checks for untrusted apps with a different Smack label. That's why I added special default rules for the "User" Smack label to the Cynara database. > so maybe we could > extend <policy> element with seclabel attribute so services running > with given label are granted access to everything (as they are trusted), > while others would be denied by default: > > <policy context="default" > > <!-- allow everyone to connect to the bus --> > <allow user="*"/> > > <!-- Holes must be punched in service configuration files for > name ownership and sending method calls --> > <deny own="*"/> > <deny send_type="method_call"/> > > <!-- write the rest of default security policy. > Allow what's required for everyone, > deny everything else --> > .... > </policy> > > <!-- rules that apply to processes running with System label --> > <policy seclabel="System" > > <!-- Allow everything to be sent --> > <allow send_destination="*" eavesdrop="true" /> > <!-- Allow everything to be received --> > <allow eavesdrop="true"/> > <!-- Allow anyone to own anything --> > <allow own="*"/> > </policy> "System" would be wrong for user services. Also, what is this "seclabel" here? Are you proposing to add it? > Like with <policy user="..." >, such rules would be processed after > <policy context="default" > and thus would override default ones. > Implementation of seclabel attribute should be very similar to how it > looks for <policy user="..." > so it shouldn't be too difficult. Yes, you do ;-) While I agree that it's probably not hard to add, I'd prefer to keep the number of changes to D-Bus small. My proposal was to use the <check privilige="http://tizen.org/privilege/user"/> with a matching Cynara rule. That way we leverage existing functionality and only have to add configuration instead of more code and different configuration. -- 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
