bubblewrap icon indicating copy to clipboard operation
bubblewrap copied to clipboard

how to bind to privileged port?

Open stef opened this issue 4 years ago • 6 comments

excuse my ignorance, i spent quite some time using search engines and i could not find an answer. is it somehow possible to wrap a program that binds to a privileged port? i tried setcaping the program, i tried suiding it, i tried --cap-add cap_net_bind_service and my failure to grok this makes me feel very uncomfortable. pls enlighten me, and possibly others struggling with such simple issue..

stef avatar Oct 18 '21 20:10 stef

If you believe bubblewrap has a bug, please describe what the steps are to reproduce the bug, what you expect the result of those steps to be, and what the result actually is.

Otherwise, this is probably out-of-scope for the bubblewrap issue tracker.

i tried setcaping the program, i tried suiding it

setuid and setcap are not effective inside the bubblewrap container. If they were, that would be a serious security vulnerability, because you could use it to make a setuid-root program like sudo read configuration of your choice.

i tried --cap-add cap_net_bind_service

bubblewrap will not give you the ability to bind privileged ports if you could not already bind privileged ports outside its container. If it did, that would be a security vulnerability (privilege escalation).

smcv avatar Oct 21 '21 18:10 smcv

I'm running into the same issue right now. It's pretty easy to reproduce:

# bwrap --unshare-all --share-net --cap-add cap_net_bind_service --ro-bind /usr /usr --ro-bind /lib /lib -- nc -l 20
nc: Permission denied

Needless to say, I'm running bwrap as root.

malte-v avatar Feb 14 '22 18:02 malte-v

I think the problem is that --cap-add grants capabilities in the new user namespace, rather than the parent user namespace. That makes it pretty useless in conjunction with --unshare-user. See man 7 user_namespaces.

malte-v avatar Feb 14 '22 18:02 malte-v

my workaround was to just do a sysctl net.ipv4.ip_unprivileged_port_start=442 and thus i can bind to port 443 from inside the bubblewrap.

stef avatar Feb 14 '22 19:02 stef

anyway, this:

bubblewrap will not give you the ability to bind privileged ports if you could not already bind privileged ports outside its container. If it did, that would be a security vulnerability (privilege escalation).

is obviously true since the binary had net_bind_service as a capability.

stef avatar Feb 14 '22 19:02 stef

my workaround was to just do a sysctl net.ipv4.ip_unprivileged_port_start=442

Yep, that's what I do too. I don't think Linux supports granting parent user namespace capabilities to a child user namespace (at least I read nothing about it in the man page), so probably bubblewrap can't do much here.

malte-v avatar Feb 14 '22 21:02 malte-v