Hi,
On 11/12/2014 05:11 PM, Patrick Ohly wrote:
(snip)
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.
That sounds useful. Without actual Cynara configs, all one could test is
that illegal access gets denied. Examples for setting those up would
also be useful.
So let's start locking down D-Bus. We want a configuration where "User"
and "System" processes can do the same as before, but any other process
can only connect unless specifically enabled for certain services.
I'm only focusing on the user session bus for now. Here's my first stab
at it, placed into /etc/dbus-1/session.d/00default.conf. One of the nice
features of the new D-Bus daemon is that it monitors files there, so one
can edit and add policies in a live session.
----
<?xml version="1.0"?>
<!DOCTYPE busconfig PUBLIC "-//freedesktop//DTD D-BUS Bus Configuration 1.0//EN"
"http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd";>
<busconfig>
<policy context="default">
<!-- Holes must be punched in service configuration files for
name ownership and sending method calls -->
<deny own="*"/>
<deny send_type="method_call"/>
<!-- Reply messages (method returns, errors) are allowed by default. -->
<allow send_requested_reply="true" send_type="method_return"/>
<allow send_requested_reply="true" send_type="error"/>
<allow receive_requested_reply="true" receive_type="method_return"/>
<allow receive_requested_reply="true" receive_type="error"/>
<!-- Signals are denied by default. -->
<deny send_type="signal"/>
<!-- No other messages may be received by default. -->
<deny receive_type="method_call"/>
<deny receive_type="error"/>
<deny receive_type="signal"/>
<!-- Reply messages may be received by default -->
<allow receive_type="method_return"/>
<!-- Allow anyone to talk to the message bus -->
<allow send_destination="org.freedesktop.DBus"/>
<!-- But disallow some specific bus services -->
<deny send_destination="org.freedesktop.DBus"
send_interface="org.freedesktop.DBus"
send_member="UpdateActivationEnvironment"/>
<!-- Now punch a big hole for System and User processes: they can do
anything. -->
<check privilege="http://tizen.org/privilege/user"/>
<!-- TODO: this does not really work, we cannot have alternative privileges: allow
check="http://tizen.org/privilege/system"/ -->
</policy>
</busconfig>
----
And here's a per-service policy file /etc/dbus-1/session.d/10eds.conf:
----
<?xml version="1.0"?>
<!DOCTYPE busconfig PUBLIC "-//freedesktop//DTD D-BUS Bus Configuration 1.0//EN"
"http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd";>
<busconfig>
<policy context="default">
<!-- At least read access is needed for opening an address book. -->
<check send_destination="org.gnome.evolution.dataserver.AddressBook6"
send_interface="org.gnome.evolution.dataserver.AddressBookFactory"
send_member="OpenAddressBook"
privilege="http://tizen.org/privilege/contact.read"/>
<!-- Allow read and write access to *all* methods of an address book
instance.
Write access gets restricted again below. -->
<check send_destination="org.gnome.evolution.dataserver.AddressBook6"
send_interface="org.gnome.evolution.dataserver.AddressBook"
privilege="http://tizen.org/privilege/contact.read"/>
<!-- Anything that modifies data requires write access. -->
<check send_destination="org.gnome.evolution.dataserver.AddressBook6"
send_interface="org.gnome.evolution.dataserver.AddressBook"
send_member="CreateContacts"
privilege="http://tizen.org/privilege/contact.write"/>
<check send_destination="org.gnome.evolution.dataserver.AddressBook6"
send_interface="org.gnome.evolution.dataserver.AddressBook"
send_member="ModifyContacts"
privilege="http://tizen.org/privilege/contact.write"/>
<check send_destination="org.gnome.evolution.dataserver.AddressBook6"
send_interface="org.gnome.evolution.dataserver.AddressBook"
send_member="RemoveContacts"
privilege="http://tizen.org/privilege/contact.write"/>
<!-- TODO: org.freedesktop.DBus.Properties -->
<!-- TODO: signals -->
</policy>
</busconfig>
----
Some observations. First, the attempt above to open up access for all
user and system process doesn't work, because only the latest applicable
rule will actually checked, so basically "<allow
check="http://tizen.org/privilege/user"/>" always gets skipped in favor
of checking the latter rules in 10eds.conf. The effect is that we need
Cynara rules for all Tizen privileges that grant these privileges to
processes with User and System label - perhaps we need them anyway.
Second, the EDS rules are slightly backwards: having the contact.read
privilege basically opens up access to all methods, including those
which write, and then the check for contact.write overrides that for
some specific methods. The risk here is that adding a different write
method to the D-Bus interface without adapting the policy file will
leave that new write method accessible even if only the contact.read
privilege was granted.
So it's probably better to have one explicit rule per interface member,
even if it is more verbose.
Yes, I think that's the best option at the moment.
Here's my /var/cynara/db/_ :
testapp;5000;http://tizen.org/privilege/contact.write;0xFFFF;
testapp;5000;http://tizen.org/privilege/contact.read;0xFFFF;
User;5000;http://tizen.org/privilege/user;0xFFFF;
User;5000;http://tizen.org/privilege/contact.write;0xFFFF;
User;5000;http://tizen.org/privilege/contact.read;0xFFFF;
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
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" />
Equivalent constructs with <check> element are not supported (what's
left is to complain about them while parsing XML).
From D-Bus daemon code I see that such checks are enforced in many
places and supporting it might not be trivial and maybe not feasible.
Especially when the semantics would be a bit odd ("Allow users with
given uid/gid having certain privilege to connect to the given bus").
<check privilege="..." /> meaning "Allow apps having given privilege to
connect to the bus" makes more sense, but unless we really need it I'd
prefer not to implement it. I think that for our purposes securing
methods/signals should be enough.
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>
Rules in <policy user="user_name"> section are processed after <policy
context="default"> section meaning they will override default ones.
Consequently, unprivileged apps will be checked by Cynara for access
while trusted services won't.
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.
However, their smack label will probably be well-known 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>
In some service's configuration file:
<policy context="default >
<!--
Check for access for the given service. Rules here
won't be actually enforced for trusted services as they
will be overriden by <policy seclabel="System" > rules
-->
<check send_destination="..." send_interface="..."
send_member="..." />
...
</policy>
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.
Another solution would be to write and manage set of Cynara rules for
trusted services but that would probably mean more work.
Best regards,
--
Jacek Bukarewicz
Samsung R&D Institute Poland
Samsung Electronics
[email protected]
_______________________________________________
Dev mailing list
[email protected]
https://lists.tizen.org/listinfo/dev
