linux-kernel - Re: [PATCH] iio: misc: add a generic regulator driver

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]

Date:   Wed, 28 Dec 2016 14:08:04 +0100
From:   Linus Walleij <linus.walleij@...aro.org>
To:     Lars-Peter Clausen <lars@...afoo.de>
Cc:     Geert Uytterhoeven <geert@...ux-m68k.org>,
        Bartosz Golaszewski <bgolaszewski@...libre.com>,
        Jonathan Cameron <jic23@...nel.org>,
        Hartmut Knaack <knaack.h@....de>,
        Peter Meerwald-Stadler <pmeerw@...erw.net>,
        Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        "linux-iio@...r.kernel.org" <linux-iio@...r.kernel.org>,
        linux-devicetree <devicetree@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Kevin Hilman <khilman@...libre.com>,
        Patrick Titiano <ptitiano@...libre.com>,
        Neil Armstrong <narmstrong@...libre.com>,
        Liam Girdwood <lgirdwood@...il.com>,
        Mark Brown <broonie@...nel.org>
Subject: Re: [PATCH] iio: misc: add a generic regulator driver

On Fri, Dec 23, 2016 at 12:35 PM, Lars-Peter Clausen <lars@...afoo.de> wrote:
> On 12/23/2016 11:00 AM, Geert Uytterhoeven wrote:

> Well, it is a policy question. Who gets access to what. Right now it is all
> or nothing, a privileged application gets access to all devices/GPIOs, a
> unprivileged application gets access to nothing. Same for GPIOs as well as
> IIO devices.
>
> iiod at the moment does not have any access control at all, which in itself
> is a problem. We need to add support for that at some point. I don't see an
> issue with implementing a finer grained access scheme when we do so. E.g.
> unprivileged applications only get access to certain pins.

I don't know why this is percieved as such a big practical problem.

It seems to me as more of a theoretical exploit path than a practical one.
(Famous last words...)

We have per-device and not per-line GPIO access restrictions.
/dev/gpiochip0
/dev/gpiochip1
etc
can all have per-device access restrictions.

This is no different from /dev/sda for example. You do not have
per-sector control of the block device, because it doesn't make sense.
Either you access all of the device, or nothing.
The same goes for IIO devices.

This pattern is very clear. You get access to a whole device or none
of it.

As with disks and IIO devices, if you want more granular access
restrictions, that is policy, and should reside in userspace.

Yours,
Linus Walleij