Hello Milan,
On Mon, 1 Jul 2019, Milan Broz wrote:
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
The signature needs to be trusted by the .builtin_trusted_keys which is
a read-only list of keys that were compiled into the kernel. The
verify_pkcs7_signature verifies trust against the builtin keyring so I
think what you are suggesting is covered here.
Regards,
Jaskaran.
