All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mimi Zohar <zohar@linux.vnet.ibm.com>
To: Vivek Goyal <vgoyal@redhat.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 20:48:55 -0500	[thread overview]
Message-ID: <1359424135.3906.247.camel@falcor1> (raw)
In-Reply-To: <20130128202241.GB14405@redhat.com>

On Mon, 2013-01-28 at 15:22 -0500, Vivek Goyal wrote:
> On Mon, Jan 28, 2013 at 03:15:49PM -0500, Mimi Zohar wrote:
> > On Mon, 2013-01-28 at 13:56 -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...
> > > 
> > > One more question. I specified "ima_appraise_tcb" on kernel command line
> > > and I had an unbootable system. It refused to run "init" as it was not
> > > labeled/signed. Is there any policy/way where it appraises only signed
> > > files and does not refuse to open/execute unsigned ones.
> > 
> > The policy defines what needs to be measured/appraised, not the other
> > way around.  There's nothing preventing you from defining and loading a
> > different policy, one to your liking, before pivoting root.
> 
> Hi Mimi,
> 
> By policy you mean ima rules here? So I can either enable default rules
> (tcb default rules for appraisal and measurement) by using kernel command
> line options or dynamically configure my own rules using /sysfs interface?
> 
> If yes, AFAIK, existing inputtable policies do not allow this selective
> mode where we do appraisal only on signed executable. That means I shall
> have to extend the way policies can be specified so that one specify
> that appraise only signed files?

We've just added the ability of defining the method for appraising a
file and defining rules in terms of the filesystem UUID.  Extending the
IMA policy shouldn't be a problem, but I'm not sure how you would go
about adding support for only appraising files with digital signatures.

> Also given the fact that we allow loading policy from initramfs, root
> can rebuild initramfs and change the policy which takes effect over next
> reboot. So in priciple this works only when we are trying to impose some
> policy on non-root users?

The assumption has always been that the initramfs would be measured, for
trusted boot, and appraised, for secure boot, before being executed.

Mimi


  reply	other threads:[~2013-01-29  1:48 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-17 17:52   ` David Howells
2013-01-17 18:00     ` Kasatkin, Dmitry
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
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 [this message]
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 18:03   ` 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=1359424135.3906.247.camel@falcor1 \
    --to=zohar@linux.vnet.ibm.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=vgoyal@redhat.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.