[lkml]   [2013]   [Jan]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 2/3] binfmt_elf: Verify signature of signed elf binary
On Wed, Jan 16, 2013 at 8:21 PM, Vivek Goyal <> wrote:
> On Wed, Jan 16, 2013 at 12:24:39PM -0500, Mimi Zohar wrote:
>> On Wed, 2013-01-16 at 10:54 -0500, Vivek Goyal wrote:
>> > On Wed, Jan 16, 2013 at 10:33:11AM -0500, Mimi Zohar wrote:
>> >
>> > [..]
>> > > > - Also I really could not figure out where does the private signing key
>> > > > lives. I got the impression that we need to trust installer and
>> > > > signing somehow happens at installation time. And we wanted signing
>> > > > to happen at build server and could not trust installer for that.
>> > >
>> > > Dmitry's ima-evm-utils package signs files. Depending on the options,
>> > > both the EVM and IMA extended attributes are created.
>> >
>> > I was going through following presentation.
>> >
>> >
>> >
>> > On slide 8, it mentons signing.
>> >
>> > evmctl sign --imahash /path/to/file
>> > evmctl sign --imasig /path/to/file
>> >
>> > Can't figure out where does the key for signing come from? Is it already
>> > loaded in any of kernel keyrings.
>> >
>> > If yes, I think this is non-starter. One can not distribute the private
>> > key.
>> No, the default key location is /etc/keys/privkey_evm.pem, but can be
>> specified. Prior to Dmitry's updating the package yesterday, the last
>> parameter was the key pathname. After the update, you can specify the
>> key location with the new --key option.
>> > Also I am assuming that this is done at installation time? If yes, then
>> > again it does not work as installer does not have private key.
>> Not necessarily. The original use case scenario was creating an image
>> with both EVM and IMA digital signatures and then flashing the image.
> But distributions don't ship pre-setup root file system. It is created
> and labeled at installation time. So if we want to use IMA, we need to
> sign files at installation time. That means private keys need to be
> accessible to installer (using --key option). And that does not work for
> this use case.

This wrong again.. Private should be used during installation time at all...

>> > On slide 11, it talks about importing public keys in kernel keyring from
>> > initramfs. As we discussed this will need modification as these keys
>> > need to be signed and signing public key should already be part of
>> > kernel keyring.
>> It's been a long process upstreaming all the different pieces involved.
>> The initial design/step was to load the public key on a keyring. Since
>> then we've added support for multiple keyrings(eg. EVM, IMA, etc). The
>> next step is to tie this in with secure boot.
>> > So looking at the signing process, it really does not look like that
>> > I can sign the executable at build server. It looks it needs to be
>> > signed by installer at install time and private key needs to be available
>> > to installer?
>> No, the build server can sign the files, so the private key is not
>> required on the target. These signatures need to be included in the
>> package. Elena Reshetova gave a talk at the last LSS
>> (, describing changes to RPM to write
>> the security extended attributes.
> Following is from article.
> "The other hooks that Reshetova proposed are associated with the individual
> files in a package. Those would allow things like security labeling or
> calculating hashes on the file contents (for integrity purposes)."
> IIUC, these hooks will execute on the target. So hash and all signatures
> should still be generated on target and not build server?
> Given the fact that signatures are stored in extended attributes, to me
> the only way to sign executables in current IMA framework would to be
> prepare file system image at build server and ship that image. And
> then installer simply mounts that image (after making sure that proper
> verification keys have been loaded in kernel).
> And this image will pretty much be static. As you don't have private key
> you can't install more packages and sign these.
> So it will be something like one image per signed package (in worst case).
> I don't think starting to ship signed file system images as compared
> to signed files is a better idea.
> Thanks
> Vivek

 \ /
  Last update: 2013-01-17 16:21    [W:0.085 / U:1.812 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site