linux-integrity.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jaskaran Singh Khurana <jaskarankhurana@linux.microsoft.com>
To: Milan Broz <gmazyland@gmail.com>
Cc: linux-security-module@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-integrity@vger.kernel.org,
	linux-fsdevel@vger.kernel.org, agk@redhat.com,
	snitzer@redhat.com, dm-devel@redhat.com, jmorris@namei.org,
	scottsh@microsoft.com, ebiggers@google.com, mpatocka@redhat.com
Subject: Re: [RFC PATCH v5 1/1] Add dm verity root hash pkcs7 sig validation.
Date: Thu, 27 Jun 2019 18:52:02 -0700 (PDT)	[thread overview]
Message-ID: <alpine.LRH.2.21.1906271850280.22562@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.inter> (raw)
In-Reply-To: <568f2532-e46b-5ac7-4fc5-c96983702f2d@gmail.com>



On Thu, 27 Jun 2019, Milan Broz wrote:

> Hi,
>
> I tried to test test the patch, two comments below.
>
> On 19/06/2019 21:10, Jaskaran Khurana wrote:
>> The verification is to support cases where the roothash is not secured by
>> Trusted Boot, UEFI Secureboot or similar technologies.
>> One of the use cases for this is for dm-verity volumes mounted after boot,
>> the root hash provided during the creation of the dm-verity volume has to
>> be secure and thus in-kernel validation implemented here will be used
>> before we trust the root hash and allow the block device to be created.
>>
>> The signature being provided for verification must verify the root hash and
>> must be trusted by the builtin keyring for verification to succeed.
>>
>> The hash is added as a key of type "user" and the description is passed to
>> the kernel so it can look it up and use it for verification.
>>
>> Kernel commandline parameter will indicate whether to check (only if
>> specified) or force (for all dm verity volumes) roothash signature
>> verification.
>>
>> Kernel commandline: dm_verity.verify_sig=1 or 2 for check/force root hash
>> signature validation respectively.
>
> 1) I think the switch should be just boolean - enforce signatures for all dm-verity targets
> (with default to false/off).
>
> The rest should be handled by simple logic - if the root_hash_sig_key_desc option
> is specified, the signature MUST be validated in the constructor, all errors should cause
> failure (bad reference in keyring, bad signature, etc).
>
> (Now it ignores for example bad reference to the keyring, this is quite misleading.)
>
> If a user wants to activate a dm-verity device without a signature, just remove
> optional argument referencing the signature.
> (This is not possible with dm_verity.verify_sig set to true/on.)
>
>
> 2) All DM targets must provide the same mapping table status ("dmsetup table"
> command) as initially configured.
> The output of the command should be directly usable as mapping table constructor.
>
> Your patch is missing that part, I tried to fix it, add-on patch is here
> https://git.kernel.org/pub/scm/linux/kernel/git/mbroz/linux.git/commit/?h=dm-cryptsetup&id=a26c10806f5257e255b6a436713127e762935ad3
> (feel free to fold it in your patch)
>
>
> Thanks,
> Milan
>
Hello Milan,

Thanks for testing and reviewing this. I will take care of the above 
comments change it to a boolean and for the second point merge the add-on 
patch that you shared.

Regards,
Jaskaran

  reply	other threads:[~2019-06-28  1:52 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-19 19:10 [RFC PATCH v5 0/1] Add dm verity root hash pkcs7 sig validation Jaskaran Khurana
2019-06-19 19:10 ` [RFC PATCH v5 1/1] " Jaskaran Khurana
2019-06-25 18:20   ` Mike Snitzer
2019-06-26  5:48     ` Milan Broz
2019-08-13 18:49     ` Jaskaran Singh Khurana
2019-06-27 12:17   ` Milan Broz
2019-06-28  1:52     ` Jaskaran Singh Khurana [this message]
2019-06-27 23:41   ` Eric Biggers
2019-06-28  1:49     ` Jaskaran Singh Khurana
2019-06-28  3:00       ` Eric Biggers
2019-06-28  5:12         ` Milan Broz
2019-06-28 17:03           ` Jaskaran Singh Khurana
2019-06-28  4:00 ` [RFC PATCH v5 0/1] " Eric Biggers
2019-06-28 19:45   ` Jaskaran Singh Khurana
2019-06-28 20:34     ` Eric Biggers
2019-06-28 23:27       ` Jaskaran Singh Khurana
2019-06-29  4:01   ` James Morris
2019-07-01  9:41     ` Milan Broz
2019-07-01 17:33       ` Jaskaran Singh Khurana

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=alpine.LRH.2.21.1906271850280.22562@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.inter \
    --to=jaskarankhurana@linux.microsoft.com \
    --cc=agk@redhat.com \
    --cc=dm-devel@redhat.com \
    --cc=ebiggers@google.com \
    --cc=gmazyland@gmail.com \
    --cc=jmorris@namei.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-integrity@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=mpatocka@redhat.com \
    --cc=scottsh@microsoft.com \
    --cc=snitzer@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).