Le 13/03/2012 23:17, Paweł Lasek a écrit :
> On Sat, Mar 10, 2012 at 03:00, Tetsuo Handa
> <[email protected]> wrote:
>> Although there are several problems remaining, the next version of TOMOYO is
>> taking a concrete shape. It is designed for simplicity. For example, since
>> some
>> people complain that "who can manage domains that exceed many hundreds?", I
>> changed TOMOYO's domain management from mandatory to optional. For another
>> example, since some people complain that "I want to use black listing because
>> white listing is too much burden for me", I changed from allow-only rules to
>> allow/deny rules which resembles network packet filtering rules.
>
> Yay! While I like whitelist, allow/deny would let me do some extra
> mangling in different way.
>
Hi,
This seems to be a big change, a change that effectively changes the MAC
paradigm of TOMOYO, where it will become more resource oriented and
role-based.
My understanding after a first read of the documentation is that this
new policy syntax will be great and make MUCH easier the creation of
"allow all, tight control of a few resources" policies, especially in
the context of phones like Android, it could be very powerful to protect
your data and have fine grained access control over what process can
access your marriage photos.
But the fact that domain transitions are cut off, I understand we loose
the domain chaining that enabled policy to change its behaviour based on
execution ordering, which was powerful.
I have a hard time understanding how I could migrate my current policies
to this model as it does not seem to fit. My usage of TOMOYO is "allow
all, tight control over processes and their behaviour on resources". I
would loose the order of execution control I had with current TOMOYO, or
that would be limited to only one level if my understanding is correct.
Would you have an example of how such a policy would look like?
I did not have time to test myself yet, so it is still all a little
theoretical for me.
I guess some more sample policies would be neat to have in the
documentation. (Possible example: how to restrict wget so he gets RO
access to /usr/lib/lib*.so (needed libs) and RW access to
/home/\*/Download/\* only, and could not do anything else)
Other point, I think the grouping issue we discussed before would still
apply here. For example we could have:
$acl_priority aclgroup $groupname
audit $audit_index
$cond_priority $decision $conditions_to_allow_or_deny
with a definition of the aclgroup somewhere, like:
aclgroup $groupname
$acl_priority acl $operation1 $conditions_to_filter
$acl_priority acl $operation2 $conditions_to_filter
$acl_priority acl $operation3 $conditions_to_filter
$acl_priority acl $operation4 $conditions_to_filter
$acl_priority acl $operation5 $conditions_to_filter
$acl_priority acl $operation6 $conditions_to_filter
$acl_priority acl $operation7 $conditions_to_filter
This would make the current grouping possibilities go much further in
terms of policy writing simplification and readability, as previously
discussed.
What do you think?
Regards,
Milton
_______________________________________________
tomoyo-users-en mailing list
[email protected]
http://lists.sourceforge.jp/mailman/listinfo/tomoyo-users-en
