Re: IMA: How to manage user space signing policy with others

[Eric Paris]

I think that is what he was suggesting.  It reuses the integrity code
but it loses the integrity flexibility.  I don't think it is a good
solution   :-(

On Mon, Mar 4, 2013 at 1:59 PM, Mimi Zohar <zohar@xxxxxxxxxxxxxxxxxx> wrote:
> 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-security-module" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/