linux-crypto.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Vivek Goyal <vgoyal@redhat.com>
To: "Kasatkin, Dmitry" <dmitry.kasatkin@intel.com>
Cc: Mimi Zohar <zohar@linux.vnet.ibm.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: Tue, 29 Jan 2013 13:39:31 -0500	[thread overview]
Message-ID: <20130129183931.GB21002@redhat.com> (raw)
In-Reply-To: <CALLzPKZgbz0zCMHVbcDpHX0vv=qt+T0Gi8p+rUa70LJ0E+xrNA@mail.gmail.com>

On Tue, Jan 29, 2013 at 10:48:00AM +0200, Kasatkin, Dmitry wrote:
> On Mon, Jan 28, 2013 at 8:52 PM, Vivek Goyal <vgoyal@redhat.com> 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.
> >
> 
> I will answer directly to this email first.
> 'keyctl setperm' command is used to lock keyring from being able to
> add new keys...
> Even root is not able to revert locked keyring to original
> write-permissive mode.
> 
> root@ubuntu:~# cat /proc/keys |grep ima
> 16a4c685 I--Q---     1 perm 3f010000     0     0 keyring   _ima: 2/4
> root@ubuntu:~# keyctl setperm 379897477  0x0b010000
> root@ubuntu:~# keyctl add user testkey "testing1" 379897477
> add_key: Permission denied
> root@ubuntu:~# keyctl setperm 379897477  0x3f010000
> keyctl_setperm: Permission denied
> root@ubuntu:~# cat /proc/keys |grep ima
> 16a4c685 I--Q---     1 perm 0b010000     0     0 keyring   _ima: 3/4

Hi Dmitry,

Ok, thanks for the clarification. So from initramfs we will load the key in
IMA keyring and then lock it down.

So this boils down to trusting initramfs.  So how do we make sure that
initramfs is not compromised in secureboot environment.

As initramfs is generated dynamically, we could not sign it (no private
key on target) hence can not appraise it. So may be we need to lock down
key loading in IMA keyring in secureboot mode and ship kernel with
pre-loaded keys? Or there are other ways which have already handled this
problem.

Thanks
Vivek

  reply	other threads:[~2013-01-29 18:39 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
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 [this message]
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=20130129183931.GB21002@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).