lkml.org 
[lkml]   [2013]   [Mar]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: IMA: How to manage user space signing policy with others
    From
    Date
    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



    \
     
     \ /
      Last update: 2013-03-04 21:42    [W:3.577 / U:0.556 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site