Ability to share IPv4/IPv6 network but prevent access to abstract Unix sockets

[flxmr]

Hey all, so I was thinking about using bubblewrap for some applications, which I would like to not use in a VM and for which I kept a separate user (and added it to xhost thus basically negating any isolation...). Now I wanted to improve on this (especially as handling multiple users with shared files is a pain even with sticky bit's and ACL) and would like to run everything from one user but properly deny access to the main X(Wayland)-server and certain directories.

Unfortunately I want (IP)network access and thus I have (?) to use --share-net with bubblewrap. And this is there the plan of one user and X-isolation falls completely apart for Xwayland and bugged me on my remaining X workstation. Apparently XWayland only authenticates by user (xhost +SI:localuser:) AND X11 listens on abstract sockets by default on Linux since 2014... So there is no way to deny the bubblewrapped program access to X11 (--unshare-user seems to somehow keep the uid for socket-access purposes) if I want network with bubblewrap.

Possible mediations I see:

• would you support inclusion of a --share-net-ip option (if its possible to do, sharing IP-network access and NOT abstract sockets) - I would gladly try to understand and contribute If you point me to fitting resources
• can I somehow influence/reroute/attach to the network-namespace of the container?
• can I use nsenter before calling bubblewrap to provide my own network namespace?
• using sandstorm.io (though I miss the reference to the commandline there) or nsjail ;)

Thanks in advance for thinking about my problem!

[smcv]

if its possible to do

This is probably not possible. The namespaces bwrap uses are those provided by the Linux kernel, and the Linux kernel's network namespaces apply equally to "real networking" and abstract Unix sockets.

[flxmr]

Yeah, I read into it and there was no indication how this could be achieved. I guess I'll read further into it and add an --attach-to-ns option so I can bwrap processes to a preconfigured network namespace. I'd be happy if you'd accept a pull request once I've come around doing it.

[alexlarsson]

The tying of abstract socket to the network namespace is pretty damn crappy imho, which makes this kind of stuff way to hard. One option is to disable abstract socket listening in the X server (@nwnk, any chance this could be made the detault these days?).

However, there is another way to do this non-privileged (if a bit hacky). If you use --unshare-network in combination with https://github.com/rootless-containers/slirp4netns to do userspace ip filtering. Using slirp means a NAT-like behaviour, so its not going to work for everything but that might actually be a good thing in many usecases.

We would need to add support for binding in a tap device into the bwrap network namespace though.

[flxmr]

Well, the Xserver listening on abstract sockets was only introduced in 2014 (or so I read somewhere) so good luck changing that. For my X workstation it's not much of a problem as I can just disable this/disable xhost-localuser authentication (which still gives bubblewrapped apps access to the socket as an attack vector but no direct AP access) but for XWayland there seems to be no way to change any defaults so things like that (and such as adding a Xauthority...) won't work (and all apps which get network get X access - so much for the added security...).

And thanks for the slirp4netns-info, now I know the answer to "how to connect an unprivileged network namespace to IP". I'll look into it and if someone (a lot more experienced in C and this kind of stuff) is faster to the PR, I'm happy to test!

[flxmr]

so, seems SLIRP4NET is too complicated for me, setns will only work setuid and I can actually change defaults in Xwayland (just too dumb to Google and with Gnome it's probably not too easy). Additionally I could start the stuff I want to use in a non-rootless Xwayland session and create a very nice and complete "workspace" window with a basic X-Window-Manager (Openbox) this way. I still think setting up a custom/internet connected network ns would be cool, but it's not an immediate problem for me anymore! (dbus access is blocked thankfully when changing the uid in the machine).

Thanks for all the input!

[smcv]

https://github.com/containers/bubblewrap/issues/690#issuecomment-3143686313 suggests a possible implementation of this via Landlock, if someone wants to try implementing that.