lkml.org 
[lkml]   [2013]   [Jan]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: [PATCH 2/3] binfmt_elf: Verify signature of signed elf binary
    From
    On Wed, Jan 16, 2013 at 8:21 PM, Vivek Goyal <vgoyal@redhat.com> 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.
    >> >
    >> > http://selinuxproject.org/~jmorris/lss2011_slides/IMA_EVM_Digital_Signature_Support.pdf
    >> >
    >> > 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
    >> (http://lwn.net/Articles/518265/), 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:3.173 / U:0.196 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site