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. 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. -- James Morris <jmorris@xxxxxxxxx> -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
