From from-tomoyo-dev-en at I-love.SAKURA.ne.jp Mon Mar 12 12:47:01 2012 From: from-tomoyo-dev-en at I-love.SAKURA.ne.jp (Tetsuo Handa) Date: Mon, 12 Mar 2012 12:47:01 +0900 Subject: [tomoyo-dev-en 340] Re: [tomoyo-users-en 466] Next version of TOMOYO In-Reply-To: <4F5D249A.10507@loule.info> References: <201203101200.BGB87154.NNPStVUFtPGPFTOTPZtS@I-love.SAKURA.ne.jp> <4F5D249A.10507@loule.info> Message-ID: <201203120347.q2C3l1iM057298@www262.sakura.ne.jp> Milton Yates wrote: > Any chance the named acl_groups and multiple acl_group attribution to > domains included in the next release? I want to add them to TOMOYO 1.8 and 2.5, but I don't have a plan to add them to the next version. As explained in the online documentation, the next version no longer has domain_policy, exception_policy and profile. The next version's rule is something similar to iptables' filtering rules. Thus, I think that acl_groups support is not needed by the next version. > Let me know if I can help testing. Of course you can. The rule in the next version is collection of blocks like $acl_priority1 acl $operation1 $conditions_to_filter1 audit $audit_index $cond_priority1 $decision $conditions_to_allow_or_deny1 $cond_priority2 $decision $conditions_to_allow_or_deny2 $cond_priority3 $decision $conditions_to_allow_or_deny3 $acl_priority2 acl $operation2 $conditions_to_filter2 audit $audit_index $cond_priority1 $decision $conditions_to_allow_or_deny1 $cond_priority2 $decision $conditions_to_allow_or_deny2 $cond_priority3 $decision $conditions_to_allow_or_deny3 $acl_priority3 acl $operation3 $conditions_to_filter3 audit $audit_index $cond_priority1 $decision $conditions_to_allow_or_deny1 $cond_priority2 $decision $conditions_to_allow_or_deny2 $cond_priority3 $decision $conditions_to_allow_or_deny3 . Currently, any $operation other than permission to change policy configuration ($operation == "modify_policy"), permission to transit domain manually by writing to /proc/ccs/self_domain ($operation == "manual_domain_transition") and permission to transit domain automatically upon conditions are met ($operation == "auto_domain_transition") will not be denied unless the request matches one of $decision == "deny" line. For example, permission to open a file for reading ($operation == "read") 100 acl read audit 0 0 deny path.perm=0 1 allow 200 acl read audit 0 0 deny path.uid=1000 will not be denied unless the file's DAC permission is 0000 or the file's owner ID is 1000. But for safety, regarding $operation == "modify_policy", "manual_domain_transition" and "auto_domain_transition" cases, $operation will not be granted unless the request matches $decision == "allow" line of all blocks. For example, permission to change policy configuration 100 acl modify_policy audit 0 0 deny task.uid!=0 1 deny task.gid!=0 2 allow 200 acl modify_policy audit 0 1 allow task.exe="/usr/sbin/ccs-loadpolicy" will not allow programs other than /usr/sbin/ccs-loadpolicy to change policy configuration because the request will not explicitly match "allow" line of "200 acl modify_policy" block. What I'm dithering are that (1) Whether permission to change policy configuration should require explicit "allow" matching of all "acl modify_policy" blocks or not. Currently explicit "allow" matching is required. But this choice might be too much defensive and lead to confusion for users. Maybe we should treat "acl modify_policy" block as with "acl read" block (i.e. will not be denied unless explicitly matches one of "deny" line in all of "acl modify_policy" blocks). (2) Whether we should accept duplicated $acl_priority and $cond_priority values or not. Currently it is allowed to use duplicated $acl_priority between blocks and duplicated $acl_priority within a block (and if two has the same value, they are evaluated "first-defined, first-evaluated"). Maybe we should not accept duplicated values when considering (3) to (6). (3) How should we choose domain transition destination (which is specified using transition= argument of the "allow" lines in "acl execute" blocks) when the request matched transition= argument of the "allow" lines for multiple times. For example, 100 acl execute audit 0 1 allow path="/usr/sbin/sshd" 200 acl execute audit 0 1 allow path="/usr/sbin/sshd" transition="" 300 acl execute audit 0 1 allow path="/usr/sbin/sshd" transition=NULL 400 acl execute audit 0 1 allow path="/usr/sbin/sshd" transition="/usr/sbin/sshd" the first block does not tell whether to transit domains upon successful execve(), the second block tells to transit to "" domain upon successful execve(), the third block tells not to transit domains upon successful execve(), the fourth block tells to transit to "/usr/sbin/sshd" domain upon successful execve(). Currently, first matching transition= (in the example above, "") is used. (4) How should we choose domain transition destination (which is specified using transition= argument of the "allow" lines in "acl auto_domain_transition" blocks) when the conditions matched transition= argument of the "allow" lines for multiple times. For example, 100 acl auto_domain_transition audit 0 1 allow task.uid=1000 transition="" 200 acl auto_domain_transition audit 0 1 allow task.uid!=0 transition="" 300 acl auto_domain_transition audit 0 1 allow task.uid=0-10000 transition=NULL the first block tells to transit to "" domain when current thread's user ID became 1000, the second block tells to transit to "" domain when current thread's user ID became non-0, the third block tells not to transit domains when current thread's user ID became 0 to 10000. Currently, first matching transition= is used (i.e. in the example above, "" when current thread's user ID became 1000). (5) How should audit logs look like? Currently $acl_priority and $cond_priority is not included in the audit logs. If $acl_priority and $cond_priority are included like #2012/03/02 08:14:38# global-pid=2842 result=denied acl_priority=100 cond_priority=10 operation=read / path="/etc/shadow" task.pid=2842 task.ppid=2833 task.uid=0 task.gid=0 task.euid=0 task.egid=0 task.suid=0 task.sgid=0 task.fsuid=0 task.fsgid=0 task.type!=execute_handler task.exe="/bin/cat" task.domain="/usr/sbin/sshd" path.uid=0 path.gid=42 path.ino=33716 path.major=8 path.minor=1 path.perm=0640 path.type=file path.fsmagic=0xEF53 path.parent.uid=0 path.parent.gid=0 path.parent.ino=32769 path.parent.major=8 path.parent.minor=1 path.parent.perm=0755 path.parent.type=directory path.parent.fsmagic=0xEF53 and we accept no duplicated values fpr $acl_priority and $cond_priority, 100 acl read path="/etc/shadow" audit 1 10 deny task.exe="/bin/cat" 20 allow task.exe="/usr/bin/passwd" 30 allow task.exe="/usr/sbin/sshd" 40 deny we can do like select 100 delete 10 instead of doing select 100 acl read path="/etc/shadow" delete 10 deny task.exe="/bin/cat" when updating policy configuration. (6) Whether we should require specifying $acl_priority and $cond_priority explicitly when appending new entries? Currently, $acl_priority and $cond_priority are default to 1000 when they are not explicitly specified. But if we accept no duplicated values, we can't default to 1000. (Well, we can default to the largest priority in the block + 1 ?) Not accepting duplicated values might make it difficult to add rules.