containers / bubblewrap

Low-level unprivileged sandboxing tool used by Flatpak and similar projects
Other
3.76k stars 230 forks source link

delegated netns access #61

Open cgwalters opened 8 years ago

cgwalters commented 8 years ago

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 ?

mrunalp commented 8 years ago

I like this idea. It decouples the network setup from using a network namespace by users.

alexlarsson commented 8 years ago

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.

rhatdan commented 8 years ago

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

alexlarsson commented 8 years ago

Another alternative is to have the netns bind mounts in a named subdirectory that has the corresponding ACLs set.

rhatdan commented 8 years ago

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

theju commented 8 years ago

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 ?

cgwalters commented 8 years ago

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.

bajaarbot commented 7 years ago

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.

zackw commented 7 years ago

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:

ngortheone commented 4 years ago

+1 to this feature request

crocket commented 2 years ago

What's blocking this issue?

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.