linux-crypto.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Vivek Goyal <vgoyal@redhat.com>
To: Mimi Zohar <zohar@linux.vnet.ibm.com>
Cc: "Kasatkin, Dmitry" <dmitry.kasatkin@intel.com>,
	dhowells@redhat.com, jmorris@namei.org,
	linux-security-module@vger.kernel.org,
	linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC 1/1] ima: digital signature verification using asymmetric keys
Date: Mon, 28 Jan 2013 15:13:17 -0500	[thread overview]
Message-ID: <20130128201316.GA14405@redhat.com> (raw)
In-Reply-To: <1359402694.3906.53.camel@falcor1>

On Mon, Jan 28, 2013 at 02:51:34PM -0500, Mimi Zohar wrote:
> On Mon, 2013-01-28 at 13:52 -0500, Vivek Goyal wrote:
> > On Mon, Jan 28, 2013 at 05:20:20PM +0200, Kasatkin, Dmitry wrote:
> > 
> > [..]
> > > > Ok. I am hoping that it will be more than the kernel command line we
> > > > support. In the sense that for digital signatures one needs to parse
> > > > the signature, look at what hash algorithm has been used  and then
> > > > collect the hash accordingly. It is little different then IMA requirement
> > > > of calculating one pre-determine hash for all files.
> > > 
> > > Yes... It is obvious. It's coming.
> > > But in general, signer should be aware of requirements and limitation
> > > of the platform.
> > > It is not really a problem...
> > 
> > Ok, I have another question. I was looking at your slide deck here.
> > 
> > http://selinuxproject.org/~jmorris/lss2011_slides/IMA_EVM_Digital_Signature_Support.pdf
> > 
> > Slide 12 mentions that keys are loaded into the kernel from initramfs. If
> > "root" can load any key, what are we protecting against.
> > 
> > IOW, what good ima_appraise_tcb policy, which tries to appraise any root
> > owned file.  A root can sign all the files using its own key and load its
> > public key in IMA keyring and then integrity check should pass on all
> > root files.
> 
> > So what's the idea behind digital signature appraisal? By allowing root to
> > unconditionally load the keys in IMA keyring, it seems to circumvent the
> > appraisal mechanism.
> 
> Vivek, you're asking obvious questions, without understanding that what
> you want to do is only now possible because of the work that has gone
> into upstreaming the different components of the linux-integrity
> subsystem (eg. IMA, trusted/encrypted keys, EVM, (MPI library), and now
> IMA-appraisal).  In case you weren't aware, Dmitry made the necessary
> changes so that the MPI library could be upstreamed for
> EVM/IMA-appraisal digital signature support.

Hi Mimi,

Sure. I am just trying to understand that where are we and how can I 
help improve things so that I can achieve my objectives.

The problem I am running into is that I can't find a single good 
documentation here which explains how to use things. There is no
single .txt file in Documentation/ directory which explains current
state of affiars or which explains how to use any of the IMA/EVM
functionality. 

So I have no way left but to read code and ask obivious questions
on mailing list to figure out what components are working, what
components are work in progress or what's the intent of components
and how they are supposed to be used.

So are we saying that all the appraisal and digital signature stuff
is not useful till we figure a way out to lock down IMA keyring. Or
it is useful only when root can load the keyring but we are trying
to appraise only non-root files.

> 
> I'm pretty sure that keyrings can be locked, preventing additional keys
> from being added.  (If it isn't currently supported, it needs to be.)
> The _evm and _ima keyrings should definitely be locked.  When/how this
> is done, is yet to be defined.  I'm pretty sure there are a number of
> people thinking about this, including David Howells, Dmitry Kataskin,
> David Safford and myself.
> 
> As I previously said, the next steps are to integrate the
> EVM/IMA-appraisal public keys in a safe and trusted manner, without
> breaking the secure boot signature chain.

In a private conversation David howells mentioned that IMA keyring
should allow loading only if new key is trusted by an already loaded
key. He has already posted some patches for marking a keyring trusted
and loading keys only if it is signed by a trusted key.

We were wondring that what use case is served by allowing the root
to load keys unconditionally. By understanding the use case, atleast
one can try not to break it.

Thanks
Vivek

  reply	other threads:[~2013-01-28 20:13 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-15 10:34 [RFC 0/1] ima/evm: signature verification support using asymmetric keys Dmitry Kasatkin
2013-01-15 10:34 ` [RFC 1/1] ima: digital signature verification " Dmitry Kasatkin
2013-01-22 22:53   ` Mimi Zohar
2013-01-23  9:03     ` Kasatkin, Dmitry
2013-01-25 21:01       ` Vivek Goyal
2013-01-28 14:54         ` Kasatkin, Dmitry
2013-01-28 15:15           ` Vivek Goyal
2013-01-28 15:20             ` Kasatkin, Dmitry
2013-01-28 18:52               ` Vivek Goyal
2013-01-28 19:51                 ` Mimi Zohar
2013-01-28 20:13                   ` Vivek Goyal [this message]
2013-01-29  0:14                     ` Mimi Zohar
2013-01-29 16:30                       ` Vivek Goyal
2013-01-29  8:53                     ` Kasatkin, Dmitry
2013-01-29  8:48                 ` Kasatkin, Dmitry
2013-01-29 18:39                   ` Vivek Goyal
2013-01-28 18:56               ` Vivek Goyal
2013-01-28 20:15                 ` Mimi Zohar
2013-01-28 20:22                   ` Vivek Goyal
2013-01-29  1:48                     ` Mimi Zohar
2013-01-29 16:58                       ` Vivek Goyal
2013-01-30  6:32                         ` Matthew Garrett
2013-01-30 22:22                           ` Mimi Zohar
2013-01-29 18:20                       ` Vivek Goyal
2013-01-29 20:01                         ` Mimi Zohar
2013-01-29 20:10                           ` Vivek Goyal
2013-01-29 22:26                             ` Mimi Zohar
2013-01-16 19:45 ` [RFC 0/1] ima/evm: signature verification support " Mimi Zohar
2013-01-17 17:52 ` [RFC 1/1] ima: digital signature verification " David Howells
2013-01-17 18:00   ` Kasatkin, Dmitry
2013-01-17 18:03 ` [RFC 0/1] ima/evm: signature verification support " David Howells
2013-01-18 15:16   ` 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=20130128201316.GA14405@redhat.com \
    --to=vgoyal@redhat.com \
    --cc=dhowells@redhat.com \
    --cc=dmitry.kasatkin@intel.com \
    --cc=jmorris@namei.org \
    --cc=linux-crypto@vger.kernel.org \
    --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;
as well as URLs for NNTP newsgroup(s).