On Thu, 2013-02-28 at 17:20 -0500, Eric Paris wrote: > On Thu, Feb 28, 2013 at 4:35 PM, Vivek Goyal <vgo...@redhat.com> wrote: > > On Thu, Feb 28, 2013 at 02:23:39PM -0500, Mimi Zohar wrote: > > I think just a second for both of you to step back and see a slightly > larger picture/problem might help. > > This is a weird case where Vivek does not trust root to make the > policy decision. If the box is configured for secure boot, it needs > to make these decisions no matter what the admin wants. This is why > he talks about trying to merge multiple competing policies. The > current IMA policy is controlled by whomever can first write to the > ima policy file interface. Vivek does not want an admin to be able to > overwrite the secureboot policy. So I get why he thinks changes may > be needed to support this use case.
Nobody is saying that changes aren't necessary. > The ima_tcb policy was meant to be larger than needed to determine a > trusted computing base, but it is clearly not a superset of what he is > hoping to accomplish. The 'ima_tcb' policy is for measurement and attestation. The policy being discussed here is the 'ima_appraise_tcb' used for enforcing local file integrity. > So how do we take a system where the admin/software has some control > over the integrity policy (as it is today?) and the kernel/system > itself also has control (as Vivek wants it)? > It seems unsolved with what we have today.... Right, and merging policies won't work. I see where you're going with 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/
