no default user namespace about bubblewrap HOT 5 CLOSED

User namespaces or not, being able to do --bind /tmp/myfile /etc/passwd is scary.

Why? Further note:

since / is mounted nosuid, that does not allow root by simply running 'su' after changing passwd

The main thing we use in suid mode is PR_SET_NO_NEW_PRIVS, which turns off all privilege transitions, not just on the / mount.

running 'mkdir /test' will create a user owned directory in /

Not the real /, only the tmpfs we mount at / which is private to the container.

Basically again, the theory of operation is that PR_SET_NO_NEW_PRIVS makes it safe to allow arbitrary modifications to the container namespace.

Does this address your concerns? OK to close this then?

from bubblewrap.

User namespaces or not, being able to do --bind /tmp/myfile /etc/passwd is scary.

Why?

Sorry this was a misunderstanding.
Binding files over existing ones in a mount and user namespace is supposed to work like this.

However namespaces were not designed to allow unprivileged users to use mount namespaces outside a user namespaces.
The use of anything other then user namespaces is not permitted for unprivileged users, requiring normal users to user namespaces to utilize other namespaces.

The main thing we use in suid mode is PR_SET_NO_NEW_PRIVS, which turns off all privilege transitions, not

After getting root privileges? So no more privileges then root?
(please explain)

running 'mkdir /test' will create a user owned directory in /

Not the real /, only the tmpfs we mount at / which is private to the container.

That might still affect the applications running inside. Not sure this is unsafe but it seems weird. Maybe I'm wrong here.

Basically again, the theory of operation is that PR_SET_NO_NEW_PRIVS makes it safe to allow arbitrary modi

That does seem like a very good design choice. Still not sure it will be enough though.

If there is any way a mount namespace would allow some kind of unintentinal action when the real root user is present (meaning no user namespace), there might still be a way to exploit this.

To conclude:

When run with suid privileges bubblewrap does not use a user namespace by default.

Problem 1:
That renders the statement in the documentation false, as it says there will always be a default user namespace as mentioned above.

Fix 1: Change the documentation

Problem 2:
When running with suid on a system that supports user namespaces for privileged users only, user namespaces should still be used by default (nothing prevents this)

Fix 2: apply user namespaces even when run as privileged, making only an exception when there is no user namespace support at all

(potential) Problem 3:
Unprivileged users running namespaces outside a user namespaces by using suid is dangerous. There might be cases that are not prevented by PR_SET_NO_NEW_PRIVS and nosuid.

Fix 3: The best design choice in my opinion would be to use suid only to utilize user namespaces on systems that prevent unprivileged users from using them. After a user namespace is aquired all privileges gained by suid should be dropped for good and then all other namespaces can be used inside the user namespace. By doing so, the threat level of the application would be that same as when run without suid, as the only action suid would be used for is by design supposed to be used by unprivileged uses and any security issues that could still apply would be on a kernel level and not an issue in bubblewrap.
This would however render bubblewrap unuseable on systems without user namespace support at all. Maybe a compile option would be a solution to allow the specified designs on systems that have user namespaces.

from bubblewrap.

I agree the man page was incorrect (but note the README.md was right), and #144 addresses that.

Your "Problem" 2 and 3 I would term more "Concerns". Now, I would probably agree that using a user namespace is best practice if available, and that's why we have --unshare-user-try. There are various things like the kernel keyring which only fall under the user namespace, and people using bwrap might be surprised when containers can read their user's login keyring without it.

That said...I'm not sure I'd go so far as to make --unshare-user-try the default.

from bubblewrap.

That said...I'm not sure I'd go so far as to make --unshare-user-try the default.

Why is that? Using the best practice and most secure design where possible should be the goal, should it not?

from bubblewrap.

Since the issue with the documentation is resolved, this can be closed.
For discussing default --unshare-user-try see #145

from bubblewrap.