linux-kernel - Re: [PATCH 0/6 v10] gpio: Add block GPIO

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:	Fri, 7 Dec 2012 17:02:15 +0000
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Roland Stigge <stigge@...com.de>
Cc:	gregkh@...uxfoundation.org, grant.likely@...retlab.ca,
	linus.walleij@...aro.org, linux-kernel@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org, w.sang@...gutronix.de,
	jbe@...gutronix.de, plagnioj@...osoft.com, highguy@...il.com,
	broonie@...nsource.wolfsonmicro.com, daniel-gl@....net,
	rmallon@...il.com, tru@...k-microwave.de, sr@...x.de,
	wg@...ndegger.com
Subject: Re: [PATCH 0/6 v10] gpio: Add block GPIO

On Fri, 07 Dec 2012 13:16:33 +0100
Roland Stigge <stigge@...com.de> wrote:

> On 12/07/2012 01:06 PM, Roland Stigge wrote:
> > On 12/07/2012 11:36 AM, Alan Cox wrote:
> >>> * Device interface for userland access (alternative to sysfs)
> >>
> >> Currently we can set different permissions on different GPIO lines. Your
> >> driver change drives a truck through this facility.
> 
> What I maybe misread in your concern: The dev interface is actually an
> "alternative to sysfs for block GPIO", not considered as a replacement
> for the current sysfs interface for _single_ GPIOs.

That is the problem. If you add the driver then you can no longer
implement the same permissions per node. If I've got a typical hardened
embedded device running something like SMACK I can tie a few gpio lines
to specific tasks in the security model.

The moment there is another driver anyone who can open that driver can
bypass all the security rules being imposed.

The basic problem is that right now our mapping is

"gpio line is a file system object"

you change it to

"all gpio lines are a single file system object"

Thats a bit like moving from "each document has permissions" to "allo my
documents have one permission set between them"

That makes it a very big step backwards and a fundamental change to the
entire auth model. It's not too horrendous in the case that the block
GPIO interface is the least restrictive case, but its very bad the
other way around.

The problem isn't the block API, the problem is changing the entire file
system level view of what a GPIO is and how it is access controlled.

Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/