Date: Sat, 03 Jun 2017 08:30:18 -0400 From: Daniel Micay <danielmicay@...il.com> To: oss-security@...ts.openwall.com Subject: Re: Linux kernel: stack buffer overflow with controlled payload in get_options() function On Sat, 2017-06-03 at 12:06 +0200, Florian Weimer wrote: > On 05/30/2017 06:50 PM, Solar Designer wrote: > > I guess Daniel might be associating the other side's arguments with > > Red > > Hat's because Florian was posting from a redhat.com address. I have > > no > > idea whether Florian actually spoke on behalf of Red Hat or not, but > > I'm not a Red Hat spokesperson, and I did not speak for Red Hat. I > hope > I don't have to include a silly disclaimer in every message to counter > such assumptions. Yet you're citing Red Hat's cargo cult interpretation of secure boot and claiming that other people following a meaningful definition are wrong about it. If you don't want to act as a Red Hat spokesperson, use a personal email address and don't push poor definitions of terms based on Red Hat marketing while claiming that those are the correct ones. > > either way I think the focus on Red Hat is excessive - e.g., in the > > distros list thread on the previous issue, another distro vendor > > inquired about the proposed public disclosure date, implying they > > also > > might care. A better summary would be: understanding & opinions > > vary. > Right, I think those distributions that strive to boot under the > Microsoft trust root for UEFI Secure Boot may also have concerns about > this issue. Part of the problem with UEFI Secure Boot is that no one > has documented clear security objectives for UEFI Secure Boot. Fedora > sort of evolved into “no unsigned code running in ring 0 without > virtualization”. From what I can tell, Microsoft picked that up and > urged other distributions under their trust root to implement that as > well. So, no meaningful security objective, and not implemented in the Linux kernel or the downstream forks of it in distributions. The lockdown patches would be useful if they were complete but they aren't upstream and the connection to secure boot is bogus. Secure boot can work in a meaningful way (i.e. verifying at least a useful subset of userspace) *without* those patches since the non-verified portions can be contained without them. Making that lockdown mandatory based on secure boot simply doesn't make any sense and is clear cut cargo culting without any real meaningful objective in mind. > If restricted access to ring 0 is the goal (and I think it currently > is) Please stop misrepresenting Red Hat's interpretation of secure boot as the only one. Some of us care about meaningful security, not marketing. If you keep doing it, I'll keep pointing out what you're doing. > then Linux kernel command line parsing bugs exploitable for code > execution can be used to bypass an intended security policy, and > qualifies as a security vulnerability. Sorry, but fixing every single one of these parsing bugs doesn't provide that security property that you claim. The kernel line options trust the kernel line. There are many options placing a whole lot of trust in it. Here's why the Android-based justification given earlier is bogus: you can boot from a usb flash drive as real root, without SELinux containing the init launched from there. It has full control over the kernel. In fact, there is no way to contain real root on those devices. They have DMA access over the kernel via peripherals that are not contained by the IOMMU with APIs exposed to userspace offering that control.
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ