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

[James Bottomley]

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@xxxxxxxxxxxxxxxxxxxxx/].
> > > > > 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@lingrow:~> 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