|
Message-ID: <1496153035.941.9.camel@gmail.com> Date: Tue, 30 May 2017 10:03:55 -0400 From: Daniel Micay <danielmicay@...il.com> To: Florian Weimer <fweimer@...hat.com>, oss-security@...ts.openwall.com Cc: Roee Hay <roeehay@...il.com> Subject: Re: Linux kernel: stack buffer overflow with controlled payload in get_options() function On Tue, 2017-05-30 at 15:47 +0200, Florian Weimer wrote: > On 05/30/2017 03:25 PM, Daniel Micay wrote: > > Secure boot means verifying boot chain from a root of trust in > > hardware. > > My comments were specifically about UEFI Secure Boot, which apparently > behaves quite differently from what you expect. UEFI Secure Boot can be used for a useful verified boot implementation. It doesn't behave differently than I expect. Only covering the kernel without covering any of the userspace or even the kernel line is an incomplete implementation. It doesn't need to cover the whole userspace OS to be useful but if it doesn't even cover init and enough of the userspace OS to include some useful isolated code then it's not accomplishing anything. Secure / verified boot is useful primarily for preventing an attacker from persisting privileged code. A good implementation tries to fully prevent persistence, even of unprivileged code. The secondary value is making tampering a lot more difficult, but it can't ever fully prevent that. If there's no kernel line / userspace coverage, then it's not doing either of those... so the lack of an enforced boundary between root and the kernel at least without SELinux, etc. is an orthogonal issue to this. What security property does verified boot provide without including the kernel line and at the very least enough of the core userspace OS to do *something* useful?
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.