bubblewrap
bubblewrap copied to clipboard
delegated netns access
While we allow the creation of a new netns, we don't allow configuring it, so our current support is "host network" or "none".
It would be quite interesting to allow root to delegate access to pre-configured network namespaces to bubblewrap users. This could be something like having an extended attribute or ACL on /proc/$pid/ns/net
? (If /proc
supported xattrs which it doesn't). So maybe we define this as having a /run/bwrap/netns/$netnsname
symlink, and admins which want to grant access to a netns just do:
mkdir /run/bwrap/netns/no-vpn
ln -s /proc/$netnspid/ns/net /run/bwrap/netns/no-vpn/net
setfacl -m u:someuser:rx /run/bwrap/netns/no-vpn
And then a user could do:
bwrap --netns no-vpn
And we would try to readlink
to see whether we could call setns
?
I like this idea. It decouples the network setup from using a network namespace by users.
In general you use bind mounts of namespace nodes, not symlinks. That way you keep the namespaces alive. "ip netns" typically binds these in /var/run/netns/$NAME (see man ip-netns
). Maybe we can reuse those somehow. That would make it easy to setup such namespaces.
Unfortunately:
# setfacl -m u:alex:rx /var/run/netns/testnet
setfacl: /var/run/netns/testnet: Operation not permitted
But, i guess we could go with your approach of having a separate symlink to the /var/run/netns/$name file with an acl on.
We should probably ask the kernel guys if there was a way to allow this? If it made sense. I have a fear of symlinks, being a potential security problem.
@trevorjay PTAL
Another alternative is to have the netns bind mounts in a named subdirectory that has the corresponding ACLs set.
Opened a bugzilla to see if the kernel could be modified to allow setting of ACLs or ownership on these files. https://bugzilla.redhat.com/show_bug.cgi?id=1334771
As someone following bubblewrap and wishing for this feature, can cloning an interface into the newly created NS be an option ala https://github.com/google/nsjail ?
For the desktop use case, it might actually make the most sense for NetworkManager to support generating these network namespaces, and then we just need a convention for the "access stamp ACL file" between the two.
How about moving the process into the network namespace before calling clone()
? I see a potential --netns
and --unshare-net
as mutually exclusive options: either you join an existing network namespace, or you create a new one.
I am looking at a server use-case, where the namespace would be created and setup by a separate systemd
service.
Regarding liveness of the namespace, once an interface is pushed into the network namespace wouldn't it stay alive even if no process is active? In my limited testing I have not seen the namespace expire.
Please make sure that this feature is 100% compatible with namespaces created by ip netns create
and the behavior of ip netns exec
. That is, bubblewrap --netns foo ...
should work on a namespace created by ip netns create foo
, and (in the absence of any other configuration) should produce exactly the same network conditions for the child as ip netns exec foo ...
In addition to setting the network namespace itself, ip netns exec NAMESPACE
puts the process into a fresh mount namespace, and then remounts /sys
(so that its contents reflect the network namespace) and bind-mounts /etc/netns/NAMESPACE/whatever
over /etc/whatever
for all whatever (so, for instance, you can override /etc/resolv.conf
this way). And it also does a vrf_reset()
, which I don't know what that means.
For more information on this:
+1 to this feature request
What's blocking this issue?
- It's easy, but nobody has bothered to fix this issue.
- It's easy, but people hesitate because people think this is a bad idea.
- It's difficult to fix this issue, and bubblewrap doesn't have sufficient manpower.
With setuid privilege, this can be done easily. Joining network namespace through SUID privilege would be a fine intermediary solution until the unprivileged solution comes.