On Thu, 2013-02-28 at 10:13 -0500, Vivek Goyal wrote: > Hi Mimi, > > I am running into issues w.r.t IMA policy management and user space > signing. So thought of dropping a mail and gather some ideas. > > Currently IMA seems to able to one policy only which does not contain > conflicting rules. We have tcb policies in-built and they don't have > conflicting rules. User can put its own policy and that will replace > kernel policy (default policy). And then user is responsible for making > sure conflicting rules are not present.
The default integrity policy is a null policy, which can be replaced by specifying a boot command line option(s). The integrity policy can be replaced once, with a policy of your choice. Normally this would be done in the initramfs, before pivoting root. > Now with user space signing and secureboot, I have another set of rules > which are not compatible with existing tcb policies. I know. We've already discussed this http://marc.info/?l=linux-security-module&m=136131183031527&w=2. > This is how my > rules look like as of today. These can change based on config options. > > appraise func=BPRM_CHECK appraise_type=optional > appraise func=BPRM_POST_LOAD appraise_type=optional > > These rules are not compatible with tcp appraise rule. > > .action = APPRAISE,.fowner = GLOBAL_ROOT_UID,.flags = IMA_FOWNER > > That means in current scheme of things, multiple policies can't co-exist > together. It has few disadvantages. No, it just means the merged policy needs to make sense. The example you give doesn't. I've already suggested that you define a builtin secureboot integrity policy, which is a subset of the ima_appraise_tcb policy. If secureboot is enabled, then the secureboot integrity policy would be enabled by default, in lieu of the default null policy. I would suggest that the ima_appraise_tcb, which is more restrictive, be permitted to replace the secureboot policy. > - If we want IMA to be central point for all integrity measurement > needs, then having one policy only is very limiting. So far, you haven't made a convincing case for supporting more than one policy. If anything, you've made it very clear that merging policies needs to be well thought out. > The fact that > user can overirde that policy makes it worse as then kernel can > not impose any policy at all. The kernel IS enforcing the specified integrity policy. > IOW, if user enables user space signign in kernel, say CONFIG_BIN_SIGN=y, > then I need a way so that kernel can make sure IMA rules needed to > ensure integrity of binaries are present and can not be overruled. If you want to prohibit userspace from replacing the builtin policy, then provide a Kconfig option based on secureboot. > - Disabling policy can disable certain features in kernel. So in this > case if user overides default policy, it will disable binary signing > feature also (that too in a very unintutive way). Or, you can look at Kconfig options as a way of defining what is included in the build. The policy defines what is enabled. > One possible way could be that we allow execution of all the relevant > rules in a policy and return the ANDed results of all the rules. But > this does not go well with the result caching. Atleast current IMA > infrastructure does not allow it and might require overhaul. > In general I am concerned about increased performance overhead if we > allow multiple policies to co-exist. > > Performance overhead is a concern even without multiple policies. For > user space signing, IMA hooks will be called for file operations like > open(), mmap() etc and we don't require those to be called. I am not > sure if performance overhead is significant or not. Once things start > working, I will do some benchmarking. > > But coming back to the point, how to go about making sure user space > signing policies can't be overridden if user has enabled user space > signing feature in kernel. Vivek, there are multiple concurrent threads to this discussion. One thread discusses adding the 'optional' flag. The other thread discusses defining a new hook to appraise the kernel image being loaded. If the decision is to go forward with the latter, then this thread, using the 'optional' flag, becomes moot. With a new hook to verify kernel images, you would be able to define a single integrity rule, lets call the hook security/ima_kexec_image_check(), that would appraise the integrity of kernel images being loaded. There wouldn't be a convoluted policy that verifies the signature of binaries, if it exists, yet permits all binaries to execute, except those that failed signature verification. You wouldn't need a new capability, nor rely on the signed binary to appraise the images being loaded. If secureboot is enabled, the single secureboot integrity rule could be merged safely with other policies. thanks, Mimi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
