containers / bubblewrap

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

Can't use a custom uid/gid in the sandbox together with --dev #331

Open casipw opened 5 years ago

casipw commented 5 years ago

First of all: Thanks for your great work!

I'm running a hardened kernel where unprivileged users can't create user namespaces:

[root@machine ~]# sysctl kernel.unprivileged_userns_clone
kernel.unprivileged_userns_clone = 0

I can run a command as a different user this way:

[root@machine ~]# bwrap --bind / / --unshare-all --uid $(id -u http) --gid $(id -g http) true

However, that doesn't work with a faked /dev any more. (Note that this is just a minimum working example.)

[root@machine ~]# bwrap --bind / / --dev /dev --unshare-all --uid $(id -u http) --gid $(id -g http) true
bwrap: unshare user ns: Operation not permitted

Note that it works if I omit the --uid and --gid parameters. Is that behavior intended?

smcv commented 5 years ago

I'm running a hardened kernel where unprivileged users can't create user namespaces

Is this the same patch Debian uses?

However, that doesn't work with a faked /dev any more. (Note that this is just a minimum working example.)

When running as an unprivileged user with a setuid bwrap executable, that works for me on Debian, with a suitably adjusted uid and gid (we don't have a user or group named http, so I used www-data which I think is our equivalent).

When running bwrap as root, I get the same failure mode you do.

casipw commented 5 years ago

Is this the same patch Debian uses?

Yes.

I ended up recognizing the advantages of setuid (posted that in #181), so this issue is not relevant to me any more. I'm not sure if it's relevant elsewhere, so I would leave it up to you to close the issue.