[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130128185242.GB5868@redhat.com>
Date: Mon, 28 Jan 2013 13:52:42 -0500
From: Vivek Goyal <vgoyal@...hat.com>
To: "Kasatkin, Dmitry" <dmitry.kasatkin@...el.com>
Cc: Mimi Zohar <zohar@...ux.vnet.ibm.com>, dhowells@...hat.com,
jmorris@...ei.org, linux-security-module@...r.kernel.org,
linux-crypto@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC 1/1] ima: digital signature verification using asymmetric
keys
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.
Thanks
Vivek
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists