-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support sandbox network mode in rootless #10359
Comments
#311 answers your second question. The --rootless option skips a few security layers that can be setup by root only. |
Thanks Jing, for some context, I wanna run some arbitrary code inside gVisor, if we run it in root mode and arbitrary code break gVisor, it means it will have the root access, that's why we want to run it in rootless mode. I wonder what would be the suggested way here, should I use host network mode here(which is less secure from the network perspective), or should I try to work on supporting sandbox mode with rootless. |
gVisor re-executes itself as an unprivileged user before starting the container. Therefore, if the code manages to break gVisor, it will not have root access. When running with |
Thanks Etienne, I'm reading the code but seem gVisor only re-execute itself in rootless mode?( gvisor/runsc/specutils/namespace.go Line 251 in c8da73d
|
The re-execution I am referring to is here, which sets the UID here (and drops all capabilities on the next line).
Yes. Generally speaking, gVisor is intended to take care of doing whatever is the most secure thing to do given whatever privileges it has. |
Thanks for updating the link! Yes, the code you've linked to re-runs itself as "root" within a new namespace; this is different from "root" in the initial user namespace, and does not grant the process any additional privilege within the initial user namespace (which is where "root" access would be sensitive). Moreover, this code executes as part of the |
That makes sense, thanks. One more clarification on
I'm thinking about the case that attacker would escape the container and get the original root privileges. Or are we saying since we've drop all capabilities, even attacker manages escaping from the container, they are unable to get the root privileges either. But should we still have the concern about the file access? |
Correct. If the code inside the container manages to get the privileges of the
Before running any container code, Additionally, if you use |
Description
I'm not sure if it's WAI, is it possible to do runsc run in rootless with sandbox network mode?
Based on my understanding, sandbox network mode is securer but root mode is less securer, is it contradictory? Thanks
Is this feature related to a specific bug?
No response
Do you have a specific solution in mind?
No response
The text was updated successfully, but these errors were encountered: