linux-integrity.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Milan Broz <gmazyland@gmail.com>
To: James Morris <jmorris@namei.org>, Eric Biggers <ebiggers@kernel.org>
Cc: Jaskaran Khurana <jaskarankhurana@linux.microsoft.com>,
	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, scottsh@microsoft.com,
	mpatocka@redhat.com
Subject: Re: [RFC PATCH v5 0/1] Add dm verity root hash pkcs7 sig validation.
Date: Mon, 1 Jul 2019 11:41:37 +0200	[thread overview]
Message-ID: <749ddf56-3cb6-42c8-9ccc-71e09558400f@gmail.com> (raw)
In-Reply-To: <alpine.LRH.2.21.1906282040490.15624@namei.org>

On 29/06/2019 06:01, James Morris wrote:
> On Thu, 27 Jun 2019, Eric Biggers wrote:
> 
>> 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.
> 
> Let's say the system has a policy where all code must be signed with a 
> valid key, and that one mechanism for enforcing this is via signed 
> dm-verity volumes. Validating the signature within the kernel provides 
> stronger assurance than userspace validation. The kernel validates and 
> executes the code, using kernel-resident keys, and does not need to rely 
> on validation which has occurred across a trust boundary.

Yes, but as it is implemented in this patch, a certificate is provided as
a binary blob by the (super)user that activates the dm-verity device.

Actually, I can put there anything that looks like a correct signature (self-signed
or so), and dm-verity code is happy because the root hash is now signed.

Maybe could this concept be extended to support in-kernel compiled certificates?

I like the idea of signed root hash, but the truth is that if you have access
to device activation, it brings nothing, you can just put any cert in the keyring
and use it.

Milan

> 
> You don't need arbitrary CAP_SYS_ADMIN code execution, you just need a 
> flaw in the app (or its dependent libraries, or configuration) which 
> allows signature validation to be bypassed.
> 
> The attacker now needs a kernel rather than a userspace vulnerability to 
> bypass the signed code policy.
> 

  reply	other threads:[~2019-07-01  9:41 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
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 [this message]
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=749ddf56-3cb6-42c8-9ccc-71e09558400f@gmail.com \
    --to=gmazyland@gmail.com \
    --cc=agk@redhat.com \
    --cc=dm-devel@redhat.com \
    --cc=ebiggers@kernel.org \
    --cc=jaskarankhurana@linux.microsoft.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).