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

[Vivek Goyal]

On Thu, Feb 28, 2013 at 10:13:33AM -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.
> 
> Now with user space signing and secureboot, I have another set of rules
> which are not compatible with existing tcb policies. 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.
> 
> - If we want IMA to be central point for all integrity measurement
>   needs, then having one policy only is very limiting. The fact that
>   user can overirde that policy makes it worse as then kernel can
>   not impose any policy at all.
> 
>   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.
> 
> - 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).
> 
> 
> 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.

Thinking more about it, even if something could be done where multiple
rules (kernel and user specified one) could co-exist, I think there will
be issues. One issue could override other in incompatible way.

For example, one of the limitations of current IMA infrastructures is
that it does not cover the case of somebody writing to thd disk directly
(by bypassing the filesystem). If IMA has cached previous appraisal
result, next time IMA will simply say file integrity is fine. This
probably worked so far, but certainly does not work for my case where
I want to verify file signature everytime and no result caching.

I thought I could extend IMA rule syntax and mention that results of
particular rule should not be cached. For example,

cache_result = no

So one could say

appraise bprm_check appraise_type=optional cache_result=no

But then an user space policy could overide it by specifying

appraise bprm_check appraise_type=optional 

Or something simlar. And results will be cached and calling code will
assume that signatures of binary are fine. But that's not the case.

So we need few more things from IMA for it to support the case of user
space signing.

- Ability to make sure kernel specified rules can not be overridden.
- Ability to not cache results so that direct writes to disk could
  be detected.

Till then I can't see how can I use IMA to implement process signing.

Thanks
Vivek
--
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/