lkml.org 
[lkml]   [2013]   [Mar]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: IMA: How to manage user space signing policy with others
On Tue, Mar 05, 2013 at 03:40:18PM -0500, Mimi Zohar wrote:

[..]
> > The fact that we are able to replace ima_mem_exec policy using command
> > line, binary loader will need a way to query IMA to find what's the
> > current policy. If ima_mem_exec has been replaced, then binary loader
> > will not memlock files and will not raise extra capability to binary. And
> > this will disable kdump functionality on secureboot platforms. (Something
> > which I don't like much).
>
> Ok

Hi Mimi,

Again, throwing out another idea and see if it has any merit.

I think there are quite a few issues with trying to use IMA only with
the help of policy interface. Different subsystems might have different
needs and we don't have a way to support multiple policies. How about
if we extend IMA to also provide callable function interface and
subsystems can directly call into IMA for integrity verification.

Following are some of the problems I am facing with trying to
scale policy based interface.

- Being able to support only one policy at a time creates conflict
between various users of IMA subsystem. Creating a policy which
meets the needs of all subsystem is not practical. And retaining
on policy only serves select use case and disable rest of the
use cases. What we want is to be able to serve multiple use cases
at the same time.

For example, in above case, very soon I might want to also create
a mechanism to verify signature of bzImage loaded by kexec. Say,
mmap() system call is extended to verify signature of mapped file,
or a new system call is created. In that case there will be another
set of rules and cramming them into mem_exec policy will be odd.

- Because policy can be replaced easily, some of the functionality
will automatically be disabled. (because associated policy is not
there any more). And this can be very unintutive.

For example, even if we do put new rules in mem_exec policy, this
policy can easily be replaced. And kernel loses the capability to
verify signatures of mmaped files. It will be kind of big surprise
where a system call feature disappears because somebody wrote a very
simple policy through "policy" interface. If nothing else, it is
unintutive to me.

- One more issue with "policy" based interface is that rules get
evaluated for every security hook. So though I might want to only
appraise files on exec() but on every security hook (file open, mmap etc),
IMA will go through the rule list and see if some rule matches. This can
add to performance overhead.

- There are other optimization opportunities. For example, in case of
exec() verification, initially I just want to find out if file being
executed has digital signatures or not. But bprm_check() will go ahead
and appraise the file. The appraisal which matters to us is the one
which happens in post_load(). So there is double appraisal for every
executable.

- In an attempt to meet new requirements, we are quickly eating all
the flag space and very few bits are left and further scaling can
become very difficult.

I am beginning to get the feeling that probably using "policy" based
interface is not the best to cater to wide variety of needs. What
if we can provide a set of functions which can be directly called
by various subsystem. That way we will make reuse of IMA code and
at the same time not worry about clash with other policies. Policy
based interface will continue to work as it.

New set of callable functions will primarily be for appraise purposes.
These will retrieive security.ima (and security.evm if EVM is configured),
do integrity verification and return the result to caller. There will
be no caching of results involved.

This should simplify things. It should reduce policy contentions. On
every hook we don't have to go through all the policy rules. Internal
of IMA subsystems remain less complicated etc.

There will be no need for extensions like appraise_type = optional. Caller
of IMA function will decide whether to allow access or not based on
return result. Whether access is optional or not will depend on caller.
IMA will just provide integrity result and will not mandate whether to
allow access or not.

By default interface will not cache results. So there is no need to
worry about providing cache_result=no extensions.

Mimi, what do you think. Does it make any sense?

Thanks
Vivek


\
 
 \ /
  Last update: 2013-03-06 17:43    [W:0.090 / U:0.080 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site