Re: Linux kernel: stack buffer overflow with controlled payload in get_options() function

[Daniel Micay <danielmicay () gmail com>]

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.