Hi Tetsuo,
Le 31/03/2012 04:52, Tetsuo Handa a écrit :
> Although the new version inherits some of TOMOYO's characteristic points (e.g.
> check various parameters which can be represented as string and numeric data),
> usage of the new version became completely different. I came to strongly feel
> that I should not call the new version TOMOYO. Otherwise, users and
> researchers
> who know TOMOYO shall be confused by the paradigm changes. Therefore, I
> decided
> to give the new version a new name and created a new project on
> SourceForge.jp.
I think it is probably the best choice too (for what it's worth ^^).
>> My question then is will TOMOYO 1.x/2.x be discontinued in the near
>> future?
> I'm not planning to discontinue TOMOYO 1.x/2.x in the near future.
Great :)
>> So what general use cases do you think this new version will respond to?
>
> A developer who was interested in TOMOYO suggested us to
>
> (1) Implement as a loadable kernel module that can be added to RHEL4/5
> kernels.
> (2) Allow use of blacklisting.
> [...]
Thanks a lot for explaining the rationale behind this new software, it
is a very interesting read and I'm looking forward to testing Caitsith
too now (especially as I loved FF7 ^^).
>> I was probably not clear enough on this. The idea would be that, instead
>> of having a set of ALLOW/AUDIT/DENY rules for _each_ resource operation
>> (so N acl to write), we could have a set of ALLOW/AUDIT/DENY of _many_
>> resource operations at once (so 1 acl to write + the grouping of the
>> resources/operations).
>
> Grouping resources are supported by "string_group", (which is called
> "path_group" in TOMOYO 1.x/2.x), "number_group" and "ip_group" (which is
> called
> "address_group" in TOMOYO 1.x/2.x).
>
> But how do you plan to group operations (because acceptable conditions depend
> on operations)?
Exactly, that is why some new directive would be needed to define the
grouping of acls.
Based on:
$acl_priority acl $operation $conditions_to_filter
audit $audit_index
$cond_priority $decision $conditions_to_allow_or_deny
If you have 3 ACLs with the same $decision &
$conditions_to_allow_or_deny, like these:
"
1 acl read path="/usr/share/\{\*\}/\*"
audit 1
1 allow $condition_to_allow_or_deny1
2 deny
2 acl read path="/usr/lib/lib\*.so\*"
audit 1
1 allow $conditions_to_allow_or_deny1
2 deny
3 acl read path="/etc/example"
audit 1
1 allow $conditions_to_allow_or_deny1
2 deny
"
We could have instead:
"
1 aclgroup NAMEOFGROUP
audit 1
1 allow $condition_to_allow_or_deny1
2 deny
"
where aclgroup NAMEOFGROUP would be defined somewhere, for example like
this :
"
def aclgroup NAMEOFGROUP
1 acl read path="/usr/share/\{\*\}/\*"
2 acl read path="/usr/lib/lib\*.so\*"
3 acl read path="/etc/example"
"
This would enable creation of ACL groups with names. Hope that makes
sense. Although I'm not clear how that could be implemented with the
priorities you have now on ACLs with Caitsith.
That's just an idea...
I'll stop discussing it here as there is a new project now for this ;)
Congrats.
On the same topic, I would be glad to test your patch for acl grouping
for TOMOYO, if you can send it to me. I can try and take a look at the
problem you were mentioning with too many cookie variables.
Regards,
Milton
_______________________________________________
tomoyo-users-en mailing list
[email protected]
http://lists.sourceforge.jp/mailman/listinfo/tomoyo-users-en
