how to bind to privileged port?
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..
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).
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.
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.
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.
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.
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.