netdev - Re: [RFC PATCH iproute2-next 0/5] Persisting of mount namespaces along with network namespaces

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, 11 Oct 2023 09:55:08 -0500
From: "Eric W. Biederman" <ebiederm@...ssion.com>
To: Toke Høiland-Jørgensen <toke@...hat.com>
Cc: David Ahern <dsahern@...il.com>,  Stephen Hemminger
 <stephen@...workplumber.org>,  netdev@...r.kernel.org,  Nicolas Dichtel
 <nicolas.dichtel@...nd.com>,  Christian Brauner <brauner@...nel.org>,
  David Laight <David.Laight@...LAB.COM>
Subject: Re: [RFC PATCH iproute2-next 0/5] Persisting of mount namespaces
 along with network namespaces

Toke Høiland-Jørgensen <toke@...hat.com> writes:

> "Eric W. Biederman" <ebiederm@...ssion.com> writes:
>
>> Toke Høiland-Jørgensen <toke@...hat.com> writes:
>>
>>> "Eric W. Biederman" <ebiederm@...ssion.com> writes:
>>>
>>>> Toke Høiland-Jørgensen <toke@...hat.com> writes:
>>>>
>>>>> "Eric W. Biederman" <ebiederm@...ssion.com> writes:
>>>>>
>>>>>> Toke Høiland-Jørgensen <toke@...hat.com> writes:

>> My proposal:
>>
>> On "ip netns add NAME"
>> - create the network namespace and mount it at /run/netns/NAME
>> - mount the appropriate sysfs at /run/netns-mounts/NAME/sys
>> - mount the appropriate bpffs at /run/netns-mounts/NAME/sys/fs/bpf
>>
>> On "ip netns delete NAME"
>> - umount --recursive /run/netns-mounts/NAME
>> - unlink /run/netns-mounts/NAME
>> - cleanup /run/netns/NAME as we do today.
>>
>> On "ip netns exec NAME"
>> - Walk through /run/netns-mounts/NAME like we do /etc/netns/NAME/
>>   and perform bind mounts.
>
> If we setup the full /sys hierarchy in /run/netns-mounts/NAME this
> basically becomes a single recursive bind mount, doesn't it?

Yes.

> What about if we also include bind mounts from the host namespace into
> that separate /sys instance? Will those be included into a recursive
> bind into /sys inside the mount-ns, or will we have to walk the tree and
> do separate bind mounts for each directory?

if /run/netns-mounts/NAME/sys has everything you want.

mount --rbind /run/netns-mounts/NAME/sys /sys

Will result in a /sys that has everything you want.

> Anyway, this scheme sounds like it'll solve the issue I was trying to
> address so I don't mind doing it this way. I'll try it out and respin
> the patch series.

Thanks that sounds like a way forward.


>>>> Mount propagation is a way to configure a mount namespace (before
>>>> creating a new one) that will cause mounts created in the first mount
>>>> namespace to be created in it's children, and cause mounts created in
>>>> the children to be created in the parent (depending on how things are
>>>> configured).
>>>>
>>>> It is not my favorite feature (it makes locking of mount namespaces
>>>> terrible) and it is probably too clever by half, unfortunately systemd
>>>> started enabling mount propagation by default, so we are stuck with it.
>>>
>>> Right. AFAICT the current iproute2 code explicitly tries to avoid that
>>> when creating a mountns (it does a 'mount --make-rslave /'); so you're
>>> saying we should change that?
>>
>> If it makes sense.
>>
>> I believe I added the 'mount --make-rslave /' because otherwise all
>> mount activity was propagating back, and making a mess.  Especially when
>> I was unmounting /sys.
>>
>> I am not a huge fan of mount propagation it has lots of surprising
>> little details that need to be set just right, to not cause problems.
>
> Ah, you were talking about propagation from inside the mountns to
> outside? Didn't catch that at first...
>
>> With my proposal above I think we could in some carefully chosen
>> places enable mount propagation without problem.
>
> One thing that comes to mind would be that if we create persistent /sys
> instances in /run/netns-mounts per the above, it would make sense for
> any modifications done inside the netns to be propagated back to the
> mount in /run; is this possible with a bind mount? Not sure I quite
> understand how propagation would work in this case (since it would be a
> separate (bind) mount point inside the namespace).

Basically yes, but the challenge is in the details.

If the initial propagation is setup properly it will work.  The
weirdness is how propagation works.  There is a weird detail that
it needs to be setup on the parent and not on the mount point.

I think the formula is something like:

mount --bind /run/netns-mounts/NAME/sys/ /run/netns-mounts/NAME/sys/
mount --make-rshared /run/netns-mounts/NAME/sys/
mount -t sysfs /run/netns-mounts/NAME/sys

My memory is that systemd by default does

mount --make-rshared /

So the challenge may be to simply limit what is propagated to a
controlled subset.

Eric