From: Jaskaran Singh Khurana <jaskarankhurana@linux.microsoft.com>
To: Eric Biggers <ebiggers@kernel.org>
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, mpatocka@redhat.com, gmazyland@gmail.com
Subject: Re: [RFC PATCH v5 0/1] Add dm verity root hash pkcs7 sig validation.
Date: Fri, 28 Jun 2019 12:45:11 -0700 (PDT) [thread overview]
Message-ID: <alpine.LRH.2.21.1906281242110.2789@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.inter> (raw)
In-Reply-To: <20190628040041.GB673@sol.localdomain>
Hello Eric,
On Thu, 27 Jun 2019, Eric Biggers wrote:
> On Wed, Jun 19, 2019 at 12:10:47PM -0700, Jaskaran Khurana wrote:
>> This patch set adds in-kernel pkcs7 signature checking for the roothash of
>> the dm-verity hash tree.
>> 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.
>>
>> Why we are doing validation in the Kernel?
>>
>> The reason is to still be secure in cases where the attacker is able to
>> compromise the user mode application in which case the user mode validation
>> could not have been trusted.
>> The root hash signature validation in the kernel along with existing
>> dm-verity implementation gives a higher level of confidence in the
>> executable code or the protected data. Before allowing the creation of
>> the device mapper block device the kernel code will check that the detached
>> pkcs7 signature passed to it validates the roothash and the signature is
>> trusted by builtin keys set at kernel creation. The kernel should be
>> secured using Verified boot, UEFI Secure Boot or similar technologies so we
>> can trust it.
>>
>> What about attacker mounting non dm-verity volumes to run executable
>> code?
>>
>> This verification can be used to have a security architecture where a LSM
>> can enforce this verification for all the volumes and by doing this it can
>> ensure that all executable code runs from signed and trusted dm-verity
>> volumes.
>>
>> Further patches will be posted that build on this and enforce this
>> verification based on policy for all the volumes on the system.
>>
>
> I don't understand your justification for this feature.
>
> If userspace has already been pwned severely enough for the attacker to be
> executing arbitrary code with CAP_SYS_ADMIN (which is what the device mapper
> ioctls need), what good are restrictions on loading more binaries from disk?
>
> Please explain your security model.
>
> - Eric
>
In a datacenter like environment, this will protect the system from below
attacks:
1.Prevents attacker from deploying scripts that run arbitrary executables on the system.
2.Prevents physically present malicious admin to run arbitrary code on the
machine.
Regards,
Jaskaran
next prev parent reply other threads:[~2019-06-28 19:45 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
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 [this message]
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.1906281242110.2789@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.inter \
--to=jaskarankhurana@linux.microsoft.com \
--cc=agk@redhat.com \
--cc=dm-devel@redhat.com \
--cc=ebiggers@kernel.org \
--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).