Hi,
On 11/04/2014 10:56 AM, Patrick Ohly wrote:
On Fri, 2014-10-31 at 19:17 +0100, Jacek Bukarewicz wrote:
Hi,
As you might know there is an idea to integrate Cynara checks into
dbus-daemon. Its implementation has been started by Patrick Ohly. I
continued this task and a version of dbus-daemon with this feature
implemented is available in my dbus sandbox.
git://review.tizen.org/platform/upstream/dbus
(sandbox/jacekbe/cynara-integration branch)
Which version of Cynara does that need?
I forgot to write about it - you should build latest version from the
tizen.org Cynara repository. The one that is published on the OBS
doesn't support asynchronous API
It would be nice to get feedback from service developers whether you
find it useful and sufficient to secure your services.
Ideally, service developers could try this version of D-Bus and see if
they notice any problems. I'm not sure if other parts of security
infrastructure are ready so such tests can be performed though.
It would be good if we could run dbus-monitor and Python scripts as if
they were less-privileged apps. Does anyone know how to do that?
For testing purposes I ran python and dbus-send based scripts. With
standard settings - user is root, smack label is "User".
I believe that for Cynara it shouldn't be much difference between such
setup and for example user bob, app label "some_unprivileged_app", but
I'll check it too.
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)
Then switch current process' smack label to "app_label" and switch to
user (e.g. bob)
echo "app_label" > /proc/self/attr/current
su bob
Also for test purposes I created python bindings for Cynara (admin and
client API) to easily set up policies and to invalidate policy when
required.
It's not production quality but it works for me. If anyone is interested
I can publish it on Cynara sandbox.
Additionally, I'd like to know whether we also need to support such
construct:
<check own="com.example.name" privilege="example.privilege" />
That is: allow only applications/services having given privilege to
own given name.
It would be if services weren't trusted or applications would like to
request some well known name on the bus. I'm not sure if that's the
case.
I think it is needed. Otherwise any app can impersonate anything
normally accessible via the user session bus and thus potentially
intercept confidential information from other apps.
But what privilege is needed to own a name on the session bus? The only
thing that I can think of is the http://tizen.org/privilege/user
privilege that I proposed in the "Tizen 3.0 Core privilege list" mail
thread.
Ok, so this bit is missing.
Also, are there resources that need multiple privileges or we can
assume that every resource maps to a single privilege?
I think at this point we can limit the checking to a single privilege.
If a D-Bus service developer needs to check for multiple privileges,
they can still call Cynara directly. If this turns out to be common
enough, we can still add it to dbus-daemon by turning the "privilege"
parameter into a comma-separated list with the meaning of "need all of
these", which will be backwards compatible.
This is also what I was thinking of. If required implementation
shouldn't be difficult
Needing one of several alternative privileges is already supported by
writing different allow rules, one for each privilege.
Actually, I changed <check> rules so they behave like <allow> and <deny>
- the last rule that applies wins. I did it for several reasons:
- consistency with how policy matching currently behave
- Cynara is only consulted if the rule is the last applicable so no
redundant Cynara requests are needed (for example when <check> is within
<policy context="default" > section and <allow> is within <policy
user="root"> section (for example - check regular apps but allow
services running with root)
- it makes it possible to avoid redoing policy check if we already
have answer from Cynara (with previous approach we were never sure
whether it's the last applicable rule)
Maybe I'm missing some required use cases that current approach
disallows (do we need alternative privileges?) so we'd have to switch
back to what you proposed, but honestly I'd prefer to stay like it is.
Thanks,
--
Jacek Bukarewicz
Samsung R&D Institute Poland
Samsung Electronics
[email protected]
_______________________________________________
Dev mailing list
[email protected]
https://lists.tizen.org/listinfo/dev
