On Sun, Mar 03, 2013 at 04:42:24PM -0500, Mimi Zohar wrote: [..] > > > We've already spoken about needing an additional hook or moving the > > > existing bprm hook. Can we defer the memory caching requirements for > > > now? > > > > Sure, additional hook is not a concern. > > > > I can defer caching discussion but I think it is important to discuss > > it now. Because it might very well affect how do we decide to handle > > multiple appraise rules/policies. So please, if possible, let us not > > defer the caching requirement discussion. > > > > My biggest concern is what if we decide to rule based caching option > > and rule gets skipped because of more restrictive rule present. > > > > appraise func=bprm_check cache_status=no > > appraise fowner=root > > > > In above case second rule will override first one and that's not what > > we want. > > I was thinking more in terms of merging flags. Merging the flags in > your example would work. > > appraise func=bprm_check appraise_type=optional cache_status=no > appraise fowner=root > example 2: merging the flags results in the 'optional' flag being set > > Unfortunately, in some cases, like in your example, the flag needs to be > set if either rule enables it. In other cases, like in the second > example, the flag should be set only if both rules enable it.
Hi Mimi, If we decide to merge flags, then practically we modified the ima_appraise_tcb policy. ima_appraise_tcb policy expects to cache the results and we will not do that. And this conflict just grows if we are forced to add more options in future. Also as you mentioned that in some cases flag merging is OR operation and in another cases it might be AND operation. And we will most likely end up hardcoding all this. I think slowly this is getting complicated and as people add more complex rules things can quickly get out of hand. I am wondering that why are we trying to make multiple policies work together. Can we try to keep it simple and say that at one point of time only one policy can be effective. It could either be a built in policy or user defined one. In fact that's how things are working right now. User defined policy replaces built-in policy. For the sake of backward compatibility "ima_tcb" and "ima_appraise_tcb" can co-exist together (like today). But ima_secureboot_policy will not be compatible with other policies. I understand that there might be a desire to use multiple policies together down the line, but I guess in that case policies need to specified using "policy" interface. And ima_secureboot will be odd man out here as it can not trust the root to specify policy. So practically ima_secureboot will be disabled. We just have to provide an IMA interface so that caller can query what's the effective policy currently. Say, IMA_POLICY_SECUREBOOT, IMA_POLICY_TCB, or IMA_POLICY_USER. Caller of the bprm_check() or bprm_post_load() can also check for current policy in force and give CAP_SIGNED only if desired policy is in effect. This reduces our options but trying to make multiple policies co-exist together is just making it complicated. We can take it up again when somebody has a strong use case of using secureboot policy along with other policies. In fact a user can still define a custom policy which is mix of multiple policies. Just that it is not compatible with "secureboot" policy because for that we can't trust "root" to define policy. Thanks Vivek -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
