Hi,
I'm one of the Tizen security framework developers and I'd like to summarize
the changes that we made since Tizen 3.0. The biggest problem of Tizen 2.X
security policy was amount of Smack rules. They were very hard to maintain
(as Smack rules were just a one, very long list) and burdened kernel with
huge amount of data it had to held and process. So we decided to do few
things, which constitute the Three Domain Model:
1) Main role of Smack should be not allowing access but separating
processes/applications. This is why applications have different Smack rules
- with this by default they have no access to each other. Of course, we
still require Smack rules for access to application paths (they have
different access types - RW, RO, public RO etc.) and for access between
applications in the same package (and some more less common cases).
2) We decided that all system services should be trusted, more or less, so
we reduced system labels mostly to these three : User (user session
services), System (system session services) and System::Privileged (system
session services with CAP_MAC_* capabilities). In Tizen 2.X almost every
service had different label, so we needed Smack rules for access from/to
application and between services itself.
3) In Tizen 2.X access to privileges was controlled by Smack labels on
services IPC (sockets, dbus, in few cases it was manually integrated) and
was stored with Smack rules. We replaced this mostly with Cynara (some
exceptions require direct access to protected resources, we use GIDs or
mount namespaces there). Cynara policy is not a simple list - it has
wildcards, it has buckets, it has redirections, different default policies
etc. This means less Smack rules (most system sockets are open for
applications) and smaller policy in general, for e.g. system services can
have access to all privileges requires only one Cynara policy rule.
4) Tizen 3.0 introduced multi-user. We had to separate the same application
between different users - with Smack it only could have been done with
separate labels. This would mean, that one instance of application would not
only have rules for every privilege, but also per every user. So already
huge amount of Smack rules would grow. This was another reason for
introducing external policy module - Cynara, which was designed to handle
policy for multi user environment.
We are working on platform, not products, so I can't give you exact change
in amount of policy for real life cases. I have some statistics from
emulator images of tizen 2.4 and tizen 5.0 :
Tizen 2.4 Tizen 5.0
Amount of unique labels 890 211
Amount of rules 14684 3524
The change is quite big, even though these are pretty minimal images. It is
worth noting, that rules in Tizen 2.4 grow quadratically for all
applications installed. In Tizen since version 3.0, we tried to minimize
this, and this grow includes only Tizen 2.4 applications with special type
of path and hybrid applications, but only in scope of same package (meaning
: hybrid applications from the same package have cross rules to each other).
TL;DR The most important is that all policy regarding privileges is moved
to Cynara, system services have only few labels and we have no impact of
multi user on amount of Smack rules.
Best regards,
Zofia Grzelewska.
-----Original Message-----
From: Dev [mailto:dev-boun...@lists.tizen.org] On Behalf Of Oliver Schmidt
Sent: Monday, January 22, 2018 11:30 AM
To: dev@lists.tizen.org
Subject: [Dev] SMACK, Cynara: How does the Three Domain Model reduce
complexity?
Hi,
I'm currently diving in to Cynara, SMACK and their usage in Tizen. According
to the wiki pages, because of the high complexity of SMACK policies in
Tizen2 you invented the Three Domain Model for Tizen3 to reduce complexity.
But I still don't see how this model can reduce complexity:
Apps for example get assigned to the "User" domain, that means they get
assigned a SMACK label of the form "User::App::AppID" which is also used by
Cynara for identifying permission requests from this app. [1]
But as SMACK labels don't have any hierarchy and labels just being ASCII
strings in a flat namespace, isn't it necessary to create new policy rules
for exactly this new label, too? So how do the 3 domains reduce the
complexity and needed amount of policy rules?
Am I just misunderstanding something?
BR
Oliver Schmidt
[1] https://wiki.tizen.org/Security/Overview
_______________________________________________
Dev mailing list
Dev@lists.tizen.org
https://lists.tizen.org/listinfo/dev
