On Tue, 2014-11-04 at 14:27 +0100, Patrick Ohly wrote:
> On Tue, 2014-11-04 at 12:56 +0100, Jacek Bukarewicz wrote:
> > A simple way of making test environment closer to the actual is to
> > create proper smack rules (same as they are for User label) and switch
> > to unprivileged user (e.g. bob):
> >
> > echo "app_label System wx" > /sys/fs/smackfs/load2
> > echo "app_label System::Shared rx" > /sys/fs/smackfs/load2
> > echo "app_label System::Run rwxat" > /sys/fs/smackfs/load2
> > echo "app_label System::Log rwxa" > /sys/fs/smackfs/load2
> > echo "app_label User::Home rwxat" > /sys/fs/smackfs/load2
> > echo "app_label User::App::Shared rwxat" > /sys/fs/smackfs/load2
> > echo "app_label _ l" > /sys/fs/smackfs/load2
> > echo "System app_label rwx" > /sys/fs/smackfs/load2
> > (Setting up rules between "User" and "app_label" would also probably
> > be needed)
>
> Some authoritative answer on how to set up Smack rules would be useful.
> I don't know enough to get this right myself.
I tried it. Here's my setup script, with some admittedly fairly
arbitrarily cut-and-pasted rules for access to User:
cat >/sys/fs/smackfs/load2 <<EOF
testapp System wx
testapp System::Shared rx
testapp System::Run rwxat
testapp System::Log rwxa
testapp User wx
testapp User::Shared rx
testapp User::Run rwxat
testapp User::Log rwxa
testapp User::Home rwxat
testapp User::App::Shared rwxat
testapp _ l
System testapp rwx
EOF
With those rules in place, user root with label "testapp" can run
dbus-monitor:
# echo testapp >/proc/self/attr/current
# /usr/bin/dbus-monitor --help
Usage: /usr/bin/dbus-monitor [--system | --session | --address ADDRESS]
[--monitor | --profile ] [watch expressions]
But user app cannot:
# su app
$ /usr/bin/dbus-monitor --help
sh: /usr/bin/dbus-monitor: Permission denied
$ ls -l /usr/bin/dbus-monitor
ls: cannot access /usr/bin/dbus-monitor: Permission denied
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:
# ls -Z /usr/bin/ | grep -v " _ "
AMB amb-get
AMB amb-get-history
AMB amb-listen
AMB amb-set
AMB ambd
User dbus-cleanup-sockets
User dbus-daemon
User dbus-monitor
User dbus-run-session
User dbus-send
User dbus-uuidgen
User modello_launcher.sh
org.tizen.mobileprint pdfinfo
org.tizen.mobileprint pdfseparate
org.tizen.mobileprint pdftoppm
org.tizen.mobileprint pdftops
org.tizen.mobileprint pdfunite
User syncevo-phone-config
User syncevo-webdav-lookup
User syncevolution
System tpcs_config.dtd
System tpcs_config.xml
Note that SyncEvolution and D-Bus were built with gbs and installed with
rpm. Is manifest handling perhaps broken when going that route?
Anyway, I fixed it manually:
# for i in /usr/bin/dbus-* /usr/bin/syncevo* /usr/lib/libsyncevolution.so.0*
/usr/lib/libdbus*; do attr -S -s SMACK64 -V _ $i; done
> 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.
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?
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.
--
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
