linux-kernel - RE: [PATCH v7 10/15] platform/x86: dell-smbios: add filtering capability for requests

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <6acfc127a7a94a9cbccfed2a35c88782@ausx13mpc124.AMER.DELL.COM>
Date:   Fri, 13 Oct 2017 17:47:08 +0000
From:   <Mario.Limonciello@...l.com>
To:     <greg@...ah.com>
CC:     <dvhart@...radead.org>, <gnomes@...rguk.ukuu.org.uk>,
        <andy.shevchenko@...il.com>, <linux-kernel@...r.kernel.org>,
        <platform-driver-x86@...r.kernel.org>, <luto@...nel.org>,
        <quasisec@...gle.com>, <pali.rohar@...il.com>, <rjw@...ysocki.net>,
        <mjg59@...gle.com>, <hch@....de>
Subject: RE: [PATCH v7 10/15] platform/x86: dell-smbios: add filtering
 capability for requests

> -----Original Message-----
> From: Greg KH [mailto:greg@...ah.com]
> Sent: Friday, October 13, 2017 10:56 AM
> To: Limonciello, Mario <Mario_Limonciello@...l.com>
> Cc: dvhart@...radead.org; gnomes@...rguk.ukuu.org.uk;
> andy.shevchenko@...il.com; linux-kernel@...r.kernel.org; platform-driver-
> x86@...r.kernel.org; luto@...nel.org; quasisec@...gle.com;
> pali.rohar@...il.com; rjw@...ysocki.net; mjg59@...gle.com; hch@....de
> Subject: Re: [PATCH v7 10/15] platform/x86: dell-smbios: add filtering capability
> for requests
> 
> Just want to respond to this part first:
> 
> On Fri, Oct 13, 2017 at 03:03:10PM +0000, Mario.Limonciello@...l.com wrote:
> > Take off your "kernel" hat and put on a "customer" hat for a few moments
> > while I try to put this in practical terms why the whitelist approach doesn't
> > scale for what I'm trying to do.
> 
> Heh, you do know my background in running an enterprise kernel team,
> right? :)
> 
> > Let's say hypothetically a future version of this series that has only whitelisted
> > commands and tokens lands in a kernel that's in the next Ubuntu LTS, RHEL
> > release etc.
> > Hardware coming out about that time works fine, you can control the various
> > knobs.  Then later that year some new headless hardware is released that has
> > zigbee controllers that work with inbox kernel drivers but you can't turn them
> > on and off any way BUT through the manageability interface (it's headless!).
> > In the manageability interface we also offer a new class/select or token that
> > can control the GPIO that turns on/off these radios.
> 
> It's the "later" that you are missing here.  We only have code today for
> hardware we have today.  If you come out with new hardware, you need new
> kernel drivers for it, and as such, "old" enterprise kernels will just
> not work properly.
> 
> It's always been that way, this is nothing new, we can't predict the
> future, and is one big reason why I think the whole "enterprise" distro
> market is wrong and going to fail in the end :)
> 
> Same goes for that new device id for the wifi chip, or the video camera
> or the fingerprint reader.  Those have to be added to the kernel, and if
> the distro so desires, backported to their old and crufty version.
> 

There's plenty of cases you're absolutely right and I have a hate/hate relationship
regarding in this area.

I was very careful in my example to pick something that it's just the manageability
interface that changes.

> This has been happening for two decades now, somehow coming up with a
> "raw" pipe from userspace to the kernel to control the hardware just
> because you don't want to update the kernel code, isn't going to solve
> the issue here (hint, you now have to update your userspace code, why is
> that suddenly easier than the kernel?)
> 

It's easier because you can control your own destiny.

Changing the kernel code means submitting something upstream, 
submitting something to -stable, convincing the enterprise distro folks
to pull in your fix, adding code to your tool to test whether the kernel
supports your newly whitelisted function adding support for this function
to the tool and then posting that tool somewhere for consumption.

Changing userspace code means changing userspace code, posting it
somewhere and you're done.

As Darren mentioned most companies are built around large organizations
with specific touch points.  The people who decide what the next features
will be for manageability aren't the same people who write the tools, who
aren't the same people that implement them in the BIOS and aren't the 
same people that would be submitting any of this into the kernel.  Asking
every new option to be whitelisted in the kernel and getting that translated
into upstream, into stable, into distros, updating tools for etc is a giant process
undertaking that companies will look at and say uh why?

I think Alan's suggestions are leading this the right way though, whitelisting
for certain unprivileged actions, blacklisting certain actions, looking for capabilities
but still letting tools with the right capabilities or permissions do what they
want to do.  It's a balancing act.