4 ms·

> Are you talking about bind-mounts? If yes, then yes you can use them. Yes, I’m referring to the bind mount capabilities. By default they are enabled, but Sin

by mroche 8y ago

> Are you talking about bind-mounts? If yes, then yes you can use them. Yes, I’m referring to the bind mount capabilities. By default they are enabled, but Singularity’s config file allow us to disable user defined mounts and set global mounts that will always be used. > Yes, this is precisely the long-term usecase we want to have. I’m confused. The situation I described was a negative where a user run container bind mounts directories they shouldn’t have access to and modifying it. Like mount host /etc to container /mnt then start editing the host systems configuration files. I may be misinterpreting your statement but I don’t see how that event should be a long term goal...

cyphar 8y ago
> Yes, I’m referring to the bind mount capabilities. Okay. Every existing container runtime supports bind-mounts. Having a global configuration for them is mostly a UX thing (you could make a wrapper in half an hour that does that). > The situation I described was a negative where a user run container bind mounts directories they shouldn’t have access to and modifying it. Oh I misunderstood your question. No, that's not possible. "Root" inside a user namespace cannot access files that the underlying user would not be able to access -- this is guaranteed by the kernel (which is why I misunderstood your question -- it's a kernel security policy which affects every process). I thought you were asking whether it's possible to run a cluster as an unprivileged user. An unprivileged user can bind-mount whatever they want, but actual file access is blocked when you would expect.
- mroche 8y ago
  As someone who doesn't know a lot of the nitty details of the kernel or containerizing, I appreciate you for taking the time explaining some of this. So just to make it completely clear in my head (sorry!), when utilizing a user namespace rootless (non-setuid) container system: * The user has complete read/write/execute to everything in the 'base' container. Anything bind-mounted in assumes the given privileges from the host system.[0] The user's context is essentially mapped to root inside the container, but not a 'true' root in the context of the host system. * The user can create/modify/run a container without needing root privileges to communicate with a daemon or any other tooling. * A user can install a rootless system to their owned directories on a host system and operate its services/tools without needing elevated privilege access. [0] In the situation where a user maps a root owned directory to its corresponding directory in the container (/usr:/usr) the container root privilege access is no longer applicable. Other permissions (rwxrwxrwx user group) also apply inside the container from bind-mounts. If the above is all true, then I think I've got it. All in all, I do think the idea of a rootless system is pretty cool. Obviously you need to be running a 3.8 or later kernel (unless backported for namespaces) and enabled in the kernel, but its cool tech. Thank you for taking the time to help me understand it better. This probably would have gone a lot faster if done in verbal conversation, so I appreciate you sticking it through :) If you don't mind me asking, what came up in your conversations with the Sylabs team? Was it a case of "we'd like to wait and see as this is new[1], not thoroughly vetted tech", not developed in-house, or they just didn't want the tool to work that way? Those are just speculations I can come up with off the top of my head. If you don't want to talk about it, that's fine, too. [1] Relatively speaking at the time. It's clearly not brand-spanking new.
  - cyphar 8y ago
    > The user has complete read/write/execute to everything in the 'base' container. Anything bind-mounted in assumes the given privileges from the host system.[0] The user's context is essentially mapped to root inside the container, but not a 'true' root in the context of the host system. Sure, but it's actually much simpler than this. User namespaces allow you to change the UID mapping of users -- and an unprivileged user can map themselves to "root" (however, on the host, the user is still the same -- this similar in concept to a PID namespace). However, in a user namespace, filesystem access (plus quite a lot of other things) are restricted based on your real UID/GID. A container image (in order to be used by a user namespace) needs to be extracted such that the owner is the user that you want to execute as. If you were using "root-ful" user namespaces then you could just chown an existing image, but for rootless you need to extract it. My OCI image tool umoci[1] has supported this extraction (it's a bit more complicated than you might think) for about 2 years now. The point is that a container image is generally just a directory (maybe it's a complicated mount hierarchy, but at the end of the day there is a directory that you can "chroot" into -- note that we actually use pivot_root but that's a different topic). > The user can create/modify/run a container without needing root privileges to communicate with a daemon or any other tooling. Yes. The idea is that if you are dropped on a box (with a new enough kernel) with just an unprivileged user, and none of the tools you need are installed, you can still run containers. So all aspects of the container runtime must not require privilege -- and runc has supported this mode since 2016 (I implemented it). > If you don't mind me asking, what came up in your conversations with the Sylabs team? The main disagreement is that they misrepresent runc on their project page[2] -- which is hosted on a .gov website no less. After that there were some further disagreements about whether rootless was something that they actually supported (they don't -- and in fact I was fairly sure I saw several vulnerabilities in their setuid helpers, but I didn't bother looking further into it). Their documentation now says that they've supported rootless containers since 2016 but I don't agree with that statement (it's also so restricted)[3]. I got (somewhat unfairly) angry with them over this whole exchange, so I don't really like discussing Singularity that much anymore. In my first talk about rootless containers, someone actually asks about Singularity[4]. [1]: https://github.com/openSUSE/umoci https://github.com/openSUSE/umoci [2]: http://singularity.lbl.gov/archive/docs/v2-2/faq#why-cant-you-just-use-runc-or-any-other-container-system-on-a-shared-system http://singularity.lbl.gov/archive/docs/v2-2/faq#why-cant-yo... [3]: https://www.sylabs.io/guides/3.0/admin-guide/security.html#how-does-singularity-do-it https://www.sylabs.io/guides/3.0/admin-guide/security.html#h... [4]: https://www.youtube.com/watch?v=r6EcUyamu94 https://www.youtube.com/watch?v=r6EcUyamu94

by mroche 8y ago

cyphar 8y ago

> Yes, I’m referring to the bind mount capabilities. Okay. Every existing container runtime supports bind-mounts. Having a global configuration for them is mostly a UX thing (you could make a wrapper in half an hour that does that). > The situation I described was a negative where a user run container bind mounts directories they shouldn’t have access to and modifying it. Oh I misunderstood your question. No, that's not possible. "Root" inside a user namespace cannot access files that the underlying user would not be able to access -- this is guaranteed by the kernel (which is why I misunderstood your question -- it's a kernel security policy which affects every process). I thought you were asking whether it's possible to run a cluster as an unprivileged user. An unprivileged user can bind-mount whatever they want, but actual file access is blocked when you would expect.

mroche 8y ago
As someone who doesn't know a lot of the nitty details of the kernel or containerizing, I appreciate you for taking the time explaining some of this. So just to make it completely clear in my head (sorry!), when utilizing a user namespace rootless (non-setuid) container system: * The user has complete read/write/execute to everything in the 'base' container. Anything bind-mounted in assumes the given privileges from the host system.[0] The user's context is essentially mapped to root inside the container, but not a 'true' root in the context of the host system. * The user can create/modify/run a container without needing root privileges to communicate with a daemon or any other tooling. * A user can install a rootless system to their owned directories on a host system and operate its services/tools without needing elevated privilege access. [0] In the situation where a user maps a root owned directory to its corresponding directory in the container (/usr:/usr) the container root privilege access is no longer applicable. Other permissions (rwxrwxrwx user group) also apply inside the container from bind-mounts. If the above is all true, then I think I've got it. All in all, I do think the idea of a rootless system is pretty cool. Obviously you need to be running a 3.8 or later kernel (unless backported for namespaces) and enabled in the kernel, but its cool tech. Thank you for taking the time to help me understand it better. This probably would have gone a lot faster if done in verbal conversation, so I appreciate you sticking it through :) If you don't mind me asking, what came up in your conversations with the Sylabs team? Was it a case of "we'd like to wait and see as this is new[1], not thoroughly vetted tech", not developed in-house, or they just didn't want the tool to work that way? Those are just speculations I can come up with off the top of my head. If you don't want to talk about it, that's fine, too. [1] Relatively speaking at the time. It's clearly not brand-spanking new.
- cyphar 8y ago
  > The user has complete read/write/execute to everything in the 'base' container. Anything bind-mounted in assumes the given privileges from the host system.[0] The user's context is essentially mapped to root inside the container, but not a 'true' root in the context of the host system. Sure, but it's actually much simpler than this. User namespaces allow you to change the UID mapping of users -- and an unprivileged user can map themselves to "root" (however, on the host, the user is still the same -- this similar in concept to a PID namespace). However, in a user namespace, filesystem access (plus quite a lot of other things) are restricted based on your real UID/GID. A container image (in order to be used by a user namespace) needs to be extracted such that the owner is the user that you want to execute as. If you were using "root-ful" user namespaces then you could just chown an existing image, but for rootless you need to extract it. My OCI image tool umoci[1] has supported this extraction (it's a bit more complicated than you might think) for about 2 years now. The point is that a container image is generally just a directory (maybe it's a complicated mount hierarchy, but at the end of the day there is a directory that you can "chroot" into -- note that we actually use pivot_root but that's a different topic). > The user can create/modify/run a container without needing root privileges to communicate with a daemon or any other tooling. Yes. The idea is that if you are dropped on a box (with a new enough kernel) with just an unprivileged user, and none of the tools you need are installed, you can still run containers. So all aspects of the container runtime must not require privilege -- and runc has supported this mode since 2016 (I implemented it). > If you don't mind me asking, what came up in your conversations with the Sylabs team? The main disagreement is that they misrepresent runc on their project page[2] -- which is hosted on a .gov website no less. After that there were some further disagreements about whether rootless was something that they actually supported (they don't -- and in fact I was fairly sure I saw several vulnerabilities in their setuid helpers, but I didn't bother looking further into it). Their documentation now says that they've supported rootless containers since 2016 but I don't agree with that statement (it's also so restricted)[3]. I got (somewhat unfairly) angry with them over this whole exchange, so I don't really like discussing Singularity that much anymore. In my first talk about rootless containers, someone actually asks about Singularity[4]. [1]: https://github.com/openSUSE/umoci https://github.com/openSUSE/umoci [2]: http://singularity.lbl.gov/archive/docs/v2-2/faq#why-cant-you-just-use-runc-or-any-other-container-system-on-a-shared-system http://singularity.lbl.gov/archive/docs/v2-2/faq#why-cant-yo... [3]: https://www.sylabs.io/guides/3.0/admin-guide/security.html#how-does-singularity-do-it https://www.sylabs.io/guides/3.0/admin-guide/security.html#h... [4]: https://www.youtube.com/watch?v=r6EcUyamu94 https://www.youtube.com/watch?v=r6EcUyamu94