lkml.org 
[lkml]   [2015]   [May]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [PATCH 0/8] MODSIGN: Use PKCS#7 for module signatures [ver #4]
    On Thu, May 21, 2015 at 2:59 PM, Luis R. Rodriguez <mcgrof@suse.com> wrote:
    > On Thu, May 21, 2015 at 2:44 PM, Andy Lutomirski <luto@amacapital.net> wrote:
    >>
    >> One option would be to add another type of verifiable thing. We can
    >> verify modules, and we should add firmware to the types of things that
    >> can be signed. We could add signing keys, too. IOW, you could ask
    >> the kernel to load a signing key with certain rights, and, if they key
    >> is validly signed by some other key that has the same rights and has a
    >> bit set saying that it can delegate those rights, then the kernel will
    >> add that signing key to the keyring.
    >>
    >> If the general infrastructure were there, this would be very little
    >> additional code.
    >
    > I really like this idea, but I've heard of many great ideas before
    > followed by nothing but vaporware. So is it a direct requirement to
    > implicate blocking a change for current module signature checking
    > strategy to a new one given the concerns you raise, or can we enable
    > those who wish to want additional better solutions as the one you
    > propose to opt-in to develop those solutions? I like the idea of the
    > later given that it seems those using the current module signing
    > infrastructure would prefer the change and enabling what you say does
    > not seem to be a not possible based on allowing that to be advanced.
    >

    From my POV (and keep in mind that I'm not really involved in this
    stuff and my POV shouldn't be treated as gospel), a firmware signature
    verification should have verification that the signature was intended
    to apply to a firmware file with the name being requested as a
    requirement. Everything else is nice-to-have.

    Given that, I would say that merely shoving firmware files through the
    module verifier as-is would not be okay. There's plenty of
    flexibility in how you fix it, though. Doing it with PKCS#7
    authenticated attributes *gag* would work, but my off-the-cuff guess
    is that making that work is actually harder, even on top of David's
    patches, than doing it from scratch. PKCS#7 is not easy to work with.

    FWIW, openssl rsautl can generate raw PKCS#1 v1.5 signatures (use
    -pkcs, not -raw). openssl pkeyutl can do PKCS#1 v2.0 (i.e. PSS)
    signatures, but you'd have to write the verifier yourself. The kernel
    already has a v1.5 verifier that even follows the best practices that
    I remember. (For v2.0, there's a security proof, so an implementation
    of the spec is actually secure and there are no "best practices" to
    worry about. v1.5 is known insecure if you implement it naively.)

    --Andy


    \
     
     \ /
      Last update: 2015-05-22 00:41    [W:3.052 / U:0.024 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site