linux-kernel - Re: [PATCH 2/4] fs: define a firmware security filesystem named fwsecurityfs

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: <10c85b8f4779700b82596c4a968daead65a29801.camel@HansenPartnership.com>
Date:   Mon, 21 Nov 2022 09:03:18 -0500
From:   James Bottomley <James.Bottomley@...senPartnership.com>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:     Nayna <nayna@...ux.vnet.ibm.com>, Nayna Jain <nayna@...ux.ibm.com>,
        linuxppc-dev@...ts.ozlabs.org, linux-fsdevel@...r.kernel.org,
        linux-efi@...r.kernel.org,
        linux-security-module <linux-security-module@...r.kernel.org>,
        linux-kernel@...r.kernel.org,
        Michael Ellerman <mpe@...erman.id.au>, npiggin@...il.com,
        christophe.leroy@...roup.eu, Dov Murik <dovmurik@...ux.ibm.com>,
        George Wilson <gcwilson@...ux.ibm.com>,
        Matthew Garrett <mjg59@...f.ucam.org>,
        Dave Hansen <dave.hansen@...el.com>,
        Benjamin Herrenschmidt <benh@...nel.crashing.org>,
        Paul Mackerras <paulus@...ba.org>,
        Russell Currey <ruscur@...sell.cc>,
        Andrew Donnellan <ajd@...ux.ibm.com>,
        Stefan Berger <stefanb@...ux.ibm.com>
Subject: Re: [PATCH 2/4] fs: define a firmware security filesystem named
 fwsecurityfs

On Mon, 2022-11-21 at 12:05 +0100, Greg Kroah-Hartman wrote:
> On Sun, Nov 20, 2022 at 10:14:26PM -0500, James Bottomley wrote:
> > On Sun, 2022-11-20 at 17:13 +0100, Greg Kroah-Hartman wrote:
> > > On Sat, Nov 19, 2022 at 01:20:09AM -0500, Nayna wrote:
> > > > 
> > > > On 11/17/22 16:27, Greg Kroah-Hartman wrote:
> > > > > On Mon, Nov 14, 2022 at 06:03:43PM -0500, Nayna wrote:
> > > > > > On 11/10/22 04:58, Greg Kroah-Hartman wrote:
> > [...]
> > > > > > > I do not understand, sorry.  What does namespaces have to
> > > > > > > do
> > > > > > > with this?
> > > > > > > sysfs can already handle namespaces just fine, why not
> > > > > > > use
> > > > > > > that?
> > > > > > Firmware objects are not namespaced. I mentioned it here as
> > > > > > an
> > > > > > example of the difference between firmware and kernel
> > > > > > objects.
> > > > > > It is also in response to the feedback from James Bottomley
> > > > > > in
> > > > > > RFC v2 [
> > > > > > https://lore.kernel.org/linuxppc-dev/41ca51e8db9907d9060cc38ad
> > > > > > b59a66dcae4c59b.camel@...senPartnership.com/].
> > > > > I do not understand, sorry.  Do you want to use a namespace
> > > > > for
> > > > > these or not?  The code does not seem to be using
> > > > > namespaces. 
> > > > > You can use sysfs with, or without, a namespace so I don't
> > > > > understand the issue here.
> > > > > 
> > > > > With your code, there is no namespace.
> > > > 
> > > > You are correct. There's no namespace for these.
> > > 
> > > So again, I do not understand.  Do you want to use filesystem
> > > namespaces, or do you not?
> > 
> > Since this seems to go back to my email quoted again, let me
> > repeat: the question isn't if this patch is namespaced; I think
> > you've agreed several times it isn't.  The question is if the
> > exposed properties would ever need to be namespaced.  This is a
> > subtle and complex question which isn't at all explored by the
> > above interchange.
> > 
> > > How again can you not use sysfs or securityfs due to namespaces? 
> > > What is missing?
> > 
> > I already explained in the email that sysfs contains APIs like
> > simple_pin_... which are completely inimical to namespacing.
> 
> Then how does the networking code handle the namespace stuff in
> sysfs?
> That seems to work today, or am I missing something?

have you actually tried?

jejb@...grow:~> sudo unshare --net bash
lingrow:/home/jejb # ls /sys/class/net/
lo  tun0  tun10  wlan0
lingrow:/home/jejb # ip link show
1: lo: <LOOPBACK> mtu 65536 qdisc noop state DOWN mode DEFAULT group
default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00

So, as you see, I've entered a network namespace and ip link shows me
the only interface I can see in that namespace (a down loopback) but
sysfs shows me every interface on the system outside the namespace.

This is pretty much the story of containers and sysfs: if you mount it
inside the container, it leaks information about the host
configuration.  Since I created a container with full root, I could
actually fiddle with the host network parameters on interfaces I
shouldn't be able to see within the container using sysfs ... which is
one reason we try to persuade people to use a user namespace instead of
full root.
 
> If the namespace support needs to be fixed up in sysfs (or in
> securityfs), then great, let's do that, and not write a whole new
> filesystem just because that's not done.

As I said: a fix is proposed for securityfs.  I think everyone in
containers concluded long ago that sysfs is too big an Augean Stable.

> Also this patch series also doesn't handle namespaces, so again, I am
> totally confused as to why this is even being discussed...

Well, it's not my patch.  I came into this saying *if* there was ever a
reason to namespace these parameters then please don't use interfaces
inimical to namespacing.  My personal view is that this should all just
go in securityfs because that defers answering the question of whether
it would eventually be namespaced.

James