Hi Tetsuo, Le 23/03/2012 10:01, Tetsuo Handa a écrit : > Milton Yates wrote: >> 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. > > Exactly. Since this is a big change, I feel that it may be no longer TOMOYO and > it should acquire a new name. But people are expecting me to keep the name > TOMOYO. Hmm... If you keep the name, then you effectively replace the old one with the one. See my question below regarding the orientation of TOMOYO. > Yes. This change is targeted for people who don't want to be bothered by > additional process identifier (so-called "domains") used by MAC > implementations. Is this Data oriented security ? ;o) >> 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. > > I think TOMOYO 1.x/2.x will fit better for Android, for Android is easier to > enumerate possible domain transition patterns than desktop and servers. One of > problems of TOMOYO 1.x/2.x is that it is impossible to enforce access control > without determining domain transition patterns. If you can determine domain > transition patterns, you will obtain a sense of ease that access requests that > do not match the domain transition patterns will not be allowed. So what general use cases do you think this new version will respond to? >> I have a hard time understanding how I could migrate my current policies >> to this model as it does not seem to fit. > > You can continue using TOMOYO 1.x/2.x if TOMOYO 1.x/2.x fits better. My question then is will TOMOYO 1.x/2.x be discontinued in the near future? Do you want to have TESTING TOMOYO and Current TOMOYO available at the same time, or does this testing TOMOYO represent the future of TOMOYO? I don't mind either way, but when you invest time in writing policies for one system I guess one would like to know he will be able to keep using them for a while. >> My usage of TOMOYO is "allow >> all, tight control over processes and their behaviour on resources". > > As I wrote above, the originally expected usage of TOMOYO was "tight control > over all processes and their behaviour on resources". If you can afford > enforcing all processes, it is the best utilization of power of TOMOYO. TOMOYO can very well be used to restrict only "exposed" softwares/services, it does not require your whole system to be under full MAC control. > by using execute handler functionality > > 0 acl execute task.type!=execute_handler > 0 allow handler="/path/to/handler" transition=NULL > > 0 acl manual_domain_transition > 0 allow task.type=execute_handler > 1 deny > > and let /path/to/handler to do > > read from /proc/ccs/self_domain > append "\000" + "name of requested program" > write to /proc/ccs/self_domain > execute "requested program" > > (using http://sourceforge.jp/projects/tomoyo/svn/view/branches/domain-transition-delegation-example.c?root=tomoyo&revision=5960&content-type=text%2Fplain&pathrev=5960 > as a proof-of-concept execute handler program). I will take a look, it seems to make the policy much harder to write if you want to keep track of the domains. >> 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 > > Since parameters which can be checked as conditions depend on operation, > $operation1 == $operation2 == $operation3 == $operation4 == $operation5 == > $operation6 == $operation7 is required. Not correct for what I wanted to say, see below. > As a result, it will look something like > > aclgroup $operation $groupname > $acl_priority acl $conditions_to_filter > $acl_priority acl $conditions_to_filter > $acl_priority acl $conditions_to_filter > $acl_priority acl $conditions_to_filter > $acl_priority acl $conditions_to_filter > $acl_priority acl $conditions_to_filter > $acl_priority acl $conditions_to_filter > > and becomes more simplified > > aclgroup $operation $groupname $conditions_to_filter > > and becomes after all > > $acl_priority acl $conditions_to_filter 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). In the example I tried to give above, $conditions_to_filter are never the same, so $operationN are not always the same and thus simplification is not possible. Sorry to keep pestering you about acl grouping, I am missing this functionality really baad ;) Regards, Milton
TOMOYO
Fork