On Mon, 2013-03-04 at 10:29 -0500, Vivek Goyal wrote: [...] > 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.
Let me get this straight. You're suggesting that distros/users will need to make a Kconfig build decision of enabling secureboot, including the secureboot built-in policy, or be allowed to enable other integrity policies. If RH enables secureboot, then no other integrity policy will be permitted. Is that what you're saying, and if so, why would I agree to this? thanks, Mimi -- 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/
