Patrick,
as you already know, buckets are sets of policies. They were introduced
in Cynara to simplify administration and boost performance a little
sometimes.
While there may be an arbitrary number of buckets, there has to be one
special
one: the MAIN[*] bucket. This is where all checks start from. No other
buckets
will be searched except situation, when one of matched policies resolves
to another bucket.
[*] In fact, it's /unnamed/ bucket, but let's call it MAIN for sake
of readability. Please don't mistake it with Security Manager's
MAIN bucket
(see below).
Example:
In MAIN bucket, there is this policy:
Client User Privilege Policy
------------------------------------------------
... ... ... ...
* * access-internet -> INTERNET
... ... ... ...
------------------------------------------------
Default policy: DENY
In INTERNET bucket:
Client User Privilege Policy
------------------------------------------------
... ... ... ...
cli-app-1 5000 access-internet ALLOW
... ... ... ...
------------------------------------------------
Default policy: DENY
Now, when you check (cli-app-1, 5000, access-internet), the procedure starts
in MAIN bucket. Then it matches the policy (*, *, access-internet) and
goes down
to INTERNET bucket. There the exact policy is found.
Of course all Cynara's rules still apply. So it will scan the rest of
INTERNET
and MAIN bucket for other potential matches. If no matching rule is found in
current bucket, it will yield default bucket's policy. This applies also to
MAIN bucket.
Moreover, you can apply special value of NONE as a default bucket policy.
If we went down the bucket and there is no matching rule, but the
default policy
is NONE, Cynara will continue, as going down this bucket never happened.
The only exception is the MAIN bucket. You cannot apply NONE as a
default policy
for MAIN bucket.
About order of buckets searching, there is absolutely no rule (except
the one,
that Cynara starts from MAIN bucket). And please remember, that the same
goes
to rules itself -- Cynara checks all matching rules in arbitrary order
and picks
"the least allowing", i.e. preferring DENY to any other. Technically,
there are
some performance optimizations, but they are irrelevant for this discussion.
Hopefully this explains buckets concept. In case of any further
question, please
don't hesitate to ask.
As for Security Manager, there is indeed more than half of dozen buckets
used:
ADMIN MANIFESTS USER_TYPE_ADMIN USER_TYPE_GUEST and more.
It's been designed this way, so it's easier to maintain them and faster to
get matching rules. But this is Tizen 3.0 specific. Other
implementations can
use buckets concept in any other way (see example above) or don't use it
at all.
Hope this helps.
--
Aleksander Zdyb
Samsung R&D Institute Poland
Samsung Electronics
On 19.08.2015 14:49, Patrick Ohly wrote:
Hello!
Is there further documentation about the Cynara "bucket" concept, in
particular an explanation how using buckets will affect privilege
checks?
The admin API [1] introduces buckets as "objects in which policies are
kept" and mentions that there is a default policy for each bucket. What
does not become clear to me is how a cynara_check() call is mapped to
buckets.
Are all buckets searched? In which order? What does it mean when a
policy refers to another bucket (example: MAIN bucket has a rule of type
0xFFFE = CYNARA_ADMIN_BUCKET pointing to bucket MANIFESTS)?
This example is part of the policy which is set by security-manager [2].
That policy also has "user profiles", which get translated into Cynara
buckets. While the exact mechanism is unclear to me, it seems that the
intention is to limit certain privileges to certain kinds of users.
Correct?
It seems that these profiles grant access to all privileges to all
users. If that's the goal, can't it be expressed a bit more concisely so
that the purpose and (eventually) exceptions from it are more obvious?
[1] https://wiki.tizen.org/wiki/Security:Cynara:API:admin
[2]
https://review.tizen.org/git?p=platform/core/security/security-manager.git;a=tree;f=policy;h=59f1fb583228c48b0b8ffa1f6a82f4887aa1a3c5;hb=refs/heads/tizen
_______________________________________________
Dev mailing list
[email protected]
https://lists.tizen.org/listinfo/dev
