From: Vivek Goyal <vgoyal@redhat.com>
To: Mimi Zohar <zohar@linux.vnet.ibm.com>
Cc: linux kernel mailing list <linux-kernel@vger.kernel.org>,
linux-security-module@vger.kernel.org
Subject: Re: IMA: How to manage user space signing policy with others
Date: Thu, 28 Feb 2013 15:57:35 -0500 [thread overview]
Message-ID: <20130228205735.GE11360@redhat.com> (raw)
In-Reply-To: <1362083401.2908.412.camel@falcor1.watson.ibm.com>
On Thu, Feb 28, 2013 at 03:30:01PM -0500, Mimi Zohar wrote:
[..]
> > 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.
>
> Our posts must have crossed -
> http://marc.info/?l=linux-security-module&m=136207944823661&w=2
>
> > - Ability to not cache results so that direct writes to disk could
> > be detected.
>
> I'm not going to argue the futility of this argument. I'll leave that
> to others more qualified. If you really are concerned, then be my guest
> and define a general 'nocaching' option, not rule specific. Replacing
> the policy won't affect the option.
>
> > Till then I can't see how can I use IMA to implement process signing.
>
> Vivek, you continue to imply that IMA doesn't cut it for your use case,
> yet ignore my suggestions.
Hi Mimi,
You asked me to not come up with new signing scheme and look into IMA
and make use of it. And that's what I am trying to do. As I continue
to do implementation, new concerns crop up and I am raising these.
I have not ignored any of your suggestions. This mail I sent before you
responded back with above mail where you seem to have suggested that
that disable "policy" interface based on kconfig option. I don't think
it was suggested in any of the mail threads before.
I have concerns w.r.t to disabling "policy" interface. This is like
choosing one feature over other. And I am concerned that somebody
will come back later that why did you disable "policy" interface and
broke my use case.
I would also like to understand that why "caching results" is not a
concern (or why argument is futile) w.r.t what I am trying to do. On
a system where whole of the user space is not signed, a root process
can go and directly write to disk and IMA will never detect it.
If remote attestation is happening, it probably is fine because no
known process is supposed to do that. And if unknown process runs, it
will be detected.
But without remote, attestation, to me it is a very valid concern
and is not addressed by current IMA implementation.
So no, I am not trying to ignore your suggestions. Just that there
are many concerns and I don't think all of my concerns have been
addressed yet.
Also if I define a separate "nocaching" option, again it will impact
the performance of other use cases IMA might have. You are saying
that choose one functionality over other and I think that probably
is not the best idea.
So to me, IMA should be beefed up to support all the use cases, instead
of hardcoding things using kconfig option and choose one functionality
over other.
Thanks
Vivek
next prev parent reply other threads:[~2013-02-28 20:57 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-28 15:13 IMA: How to manage user space signing policy with others Vivek Goyal
2013-02-28 18:51 ` Vivek Goyal
2013-02-28 20:30 ` Mimi Zohar
2013-02-28 20:57 ` Vivek Goyal [this message]
2013-03-01 1:42 ` Mimi Zohar
2013-02-28 19:23 ` Mimi Zohar
2013-02-28 20:08 ` Vivek Goyal
2013-03-01 1:45 ` Mimi Zohar
2013-02-28 21:35 ` Vivek Goyal
2013-02-28 22:20 ` Eric Paris
2013-03-01 1:49 ` Mimi Zohar
2013-03-01 12:15 ` Mimi Zohar
2013-03-01 15:28 ` Vivek Goyal
2013-03-01 18:40 ` Vivek Goyal
2013-03-01 19:39 ` Mimi Zohar
2013-03-01 21:33 ` Vivek Goyal
2013-03-03 21:42 ` Mimi Zohar
2013-03-04 15:29 ` Vivek Goyal
2013-03-04 17:46 ` Vivek Goyal
2013-03-04 18:59 ` Mimi Zohar
2013-03-04 19:15 ` Vivek Goyal
2013-03-05 1:21 ` Mimi Zohar
2013-03-05 15:18 ` Vivek Goyal
2013-03-05 20:40 ` Mimi Zohar
2013-03-05 21:53 ` Vivek Goyal
2013-03-06 15:42 ` Mimi Zohar
2013-03-06 23:55 ` Vivek Goyal
2013-03-07 1:39 ` Mimi Zohar
2013-03-07 14:36 ` Vivek Goyal
2013-03-07 15:40 ` Mimi Zohar
2013-03-07 15:53 ` Vivek Goyal
2013-03-07 17:53 ` Kasatkin, Dmitry
2013-03-07 21:56 ` Vivek Goyal
2013-03-08 8:09 ` Kasatkin, Dmitry
2013-03-08 15:40 ` Vivek Goyal
2013-03-06 15:54 ` Vivek Goyal
2013-03-06 22:48 ` Mimi Zohar
2013-03-06 23:38 ` Vivek Goyal
2013-03-07 13:38 ` Mimi Zohar
2013-03-07 14:57 ` Vivek Goyal
2013-03-04 19:19 ` Eric Paris
2013-03-04 21:47 ` Vivek Goyal
2013-03-01 2:17 ` Mimi Zohar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130228205735.GE11360@redhat.com \
--to=vgoyal@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=zohar@linux.vnet.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox