6 ms·

> Well judging by the original GitHub issue about unprivileged runc containers, the largest group of commenters is from the scientific community who are restric

by mroche 8y ago

> Well judging by the original GitHub issue about unprivileged runc containers, the largest group of commenters is from the scientific community who are restricted to not run certain programs as root. Which is why we use Singularity[0]. Apologies if I’m missing something, but to me this problem they’re trying to solve, has already been solved. As stated in the README: > Singularity is an open source container platform designed to be simple, fast, and secure. Singularity is optimized for EPC and HPC workloads, allowing untrusted users to run untrusted containers in a trusted way. Singularity ‘requires’ root or elevated privileges to create and modify containers, but running them is done in the user’s namespace with that user’s permission set. And privileges can’t be elevated during the containers runtime as there are kernel level catches that prevent sudo and su from working inside the container. In terms of the ‘static’ part, Singularity uses SquashFS to produce a single binary image, and uses the SIF (Singularity Image File) format to define applications, their dependencies, and runscripts. On top of being able to run anything inside the container with the `exec` subcommand. You can also create sandbox development images that are just a directory on disk for testing things out and installing/building tools manually, then convert it into a SIF container after for cluster deployment. Or be nicer and port your process into a recipe/definition file. Most scientific/HPC related centers have started utilizing Singularity for their container workflow. Tools like Docker are essentially banned because of their perma-root privileges[1]. [0] https://github.com/sylabs/singularity https://github.com/sylabs/singularity [1] I’m an admin who reimplemented Singularity on our university’s cluster. With a heavy need on filesystem integration (which Singularity solves with great configuration options), containers which run with root privileges would be a massive security vulnerability.

batbomb 8y ago
It should be said that Singularity does actually rely on setuid scripts to actually work with images.
- mroche 8y ago
  Is there anyway to do what it does without them? Genuine question, there’s still a lot about Linux system/user space that I’m not up to snuff on yet (part of a team here, and I don’t handle users, mostly tools). I’m trying to compare/contrast the goals of binctr to existing solutions that appear to do the same or similar thing(s) already, so I’m open to learning something new today! The only new thing I’m seeing from this solution is the ability to create containers as an unprivileged user, which for most scenarios I tend to view as a non-issue. Or am I misunderstanding that?
  - symkat 8y ago
    > The only new thing I’m seeing from this solution is the ability to create containers as an unprivileged user, which for most scenarios I tend to view as a non-issue. Or am I misunderstanding that? I believe you're mislabeling it as a non-issue, it seems to be the core problem they're trying to solve: From the blog[0]: > Yes, we all know that containers run unprivileged processes; but creating and running the containers themselves requires root privileges at some point. > What is the awesome sauce we all gain from this? > Well judging by the original GitHub issue about unprivileged runc containers, the largest group of commenters is from the scientific community who are restricted to not run certain programs as root. [0]: https://blog.jessfraz.com/post/getting-towards-real-sandbox-containers/ https://blog.jessfraz.com/post/getting-towards-real-sandbox-...
    - mroche 8y ago
      I did read the blog post, but it all seemed about running containers as unprivileged users. Being able to create is what I’m saying is a non-issue, because it only saves a single convience step of not having to upload a container built elsewhere to a cluster. And tools like Singularity have online tools (Sylabs Library, Singularity Hub) which offer remote builders for users that don’t have privileges anywhere (which is hard to find) and don’t want to build containers locally. You can then pull and run the produced container from the Singularity executable without needing root access. An alternative is a cluster could set up a single machine that gives users sudo access only on the Singularity executable and prevent the ability to bind mount, therefore creating a relatively secure build environment on-premise. However, security matters more than conviencence for HPC clusters, so we’re more inclined to tell users “do it yourself” than give them any loophole in the system. Singularity already solves the unprivileged running of containers. Unless binctr is doing something that provides a different kind of unprivileged access? I’m not trying to be thick headed, but I’m just not connecting the dots on what’s so special about this.
      - justinsaccount 8y ago
        > I’m just not connecting the dots on what’s so special about this. It's not. binctr is not special. Singularity is not special either. They are both tools that do similar things.
cyphar 8y ago
I started the rootless containers project and have had long email threads with the Singularity folks. > Which is why we use Singularity[0]. Apologies if I’m missing something, but to me this problem they’re trying to solve, has already been solved. Singularity ‘requires’ root or elevated privileges to create and modify containers, Well, Singularity came out at the same time as runc's rootless containers support was developed -- so at the time it wasn't solved at all. It required (and still requires for several operations and features) root privileges in order to work (such as suid helpers in addition to explicit root requirements). It's not acceptable for a usecase where you cannot run anything as root (not even installation scripts). That was the use-case, and rootless runc (and now thanks to Akihiro and Guiseppe, rootless Docker and Kubernetes) in theory can now work without the need for any suid helpers -- though these days there is an increasing usage of newuidmap and newgidmap (which isn't mandated for the rootless runc implementation). At the time, LXC's unprivileged containers was the closest thing and it had a few (mostly optional) suid binaries -- I wanted absolutely none. > but running them is done in the user’s namespace with that user’s permission set. And privileges can’t be elevated during the containers runtime as there are kernel level catches that prevent sudo and su from working inside the container. This last part really isn't revolutionary at all. All it really takes is a syscall and three files to write to. The hard part is getting everything else to work without root privileges.
- mroche 8y ago
  Are you a dev on binctr? Is so, the following statements are based off an assumption of yes. > Well, Singularity came out at the same time as runc's rootless containers support was developed -- so at the time it wasn't solved at all. It required (and still requires for several operations and features) root privileges in order to work (such as suid helpers in addition to explicit root requirements). Alright, but I wasn’t asking about a “back then” scenario, I was mostly trying to figure out what this offers _today_. From a Singularity end-user’s perspective, there’s only one function that requires elevated permissions, and that’s building. > It's not acceptable for a usecase where you cannot run anything as root (not even installation scripts). ... At the time, LXC's unprivileged containers was the closest thing and it had a few (mostly optional) suid binaries -- I wanted absolutely none. Now I understand what this offers and it’s overarching goal is. In my specific situation (which is the angle I’m looking at this from), that’s not really a big deal due to the way we handle global and local software installation. I understand this is not a universal situation. > This last part really isn't revolutionary at all. I don’t think I made it sound like it was revolutionary, I was just sharing what a commonly used tool in HPC does for a security measure. Based off of the binctr README: > Create fully static, including rootfs embedded, binaries that pop you directly into a container. _Can be run by an unprivileged user._ My main confusion stems from that. In comparison to Singularity, it doesn’t seem to offer anything new or noteworthy that would make me take a second look at it. The first phrase just makes me think I’m saving myself a few keystrokes as I wouldn’t have to type `singularity shell <container>` to shell into my container of choice. It just looks like yet another container solution. I still find these things cool (and their above my head in dev terms), but it feels like programming languages, a new one popping up every so often. I’m primarily looking to see what advantages (or differences in approach) this offers over Singularity, Shifter, or Charliecloud, etc for my context. At least in terms of security and efficiency.

by mroche 8y ago

batbomb 8y ago

It should be said that Singularity does actually rely on setuid scripts to actually work with images.

mroche 8y ago
Is there anyway to do what it does without them? Genuine question, there’s still a lot about Linux system/user space that I’m not up to snuff on yet (part of a team here, and I don’t handle users, mostly tools). I’m trying to compare/contrast the goals of binctr to existing solutions that appear to do the same or similar thing(s) already, so I’m open to learning something new today! The only new thing I’m seeing from this solution is the ability to create containers as an unprivileged user, which for most scenarios I tend to view as a non-issue. Or am I misunderstanding that?
- symkat 8y ago
  > The only new thing I’m seeing from this solution is the ability to create containers as an unprivileged user, which for most scenarios I tend to view as a non-issue. Or am I misunderstanding that? I believe you're mislabeling it as a non-issue, it seems to be the core problem they're trying to solve: From the blog[0]: > Yes, we all know that containers run unprivileged processes; but creating and running the containers themselves requires root privileges at some point. > What is the awesome sauce we all gain from this? > Well judging by the original GitHub issue about unprivileged runc containers, the largest group of commenters is from the scientific community who are restricted to not run certain programs as root. [0]: https://blog.jessfraz.com/post/getting-towards-real-sandbox-containers/ https://blog.jessfraz.com/post/getting-towards-real-sandbox-...
  - mroche 8y ago
    I did read the blog post, but it all seemed about running containers as unprivileged users. Being able to create is what I’m saying is a non-issue, because it only saves a single convience step of not having to upload a container built elsewhere to a cluster. And tools like Singularity have online tools (Sylabs Library, Singularity Hub) which offer remote builders for users that don’t have privileges anywhere (which is hard to find) and don’t want to build containers locally. You can then pull and run the produced container from the Singularity executable without needing root access. An alternative is a cluster could set up a single machine that gives users sudo access only on the Singularity executable and prevent the ability to bind mount, therefore creating a relatively secure build environment on-premise. However, security matters more than conviencence for HPC clusters, so we’re more inclined to tell users “do it yourself” than give them any loophole in the system. Singularity already solves the unprivileged running of containers. Unless binctr is doing something that provides a different kind of unprivileged access? I’m not trying to be thick headed, but I’m just not connecting the dots on what’s so special about this.
    - justinsaccount 8y ago
      > I’m just not connecting the dots on what’s so special about this. It's not. binctr is not special. Singularity is not special either. They are both tools that do similar things.

cyphar 8y ago

I started the rootless containers project and have had long email threads with the Singularity folks. > Which is why we use Singularity[0]. Apologies if I’m missing something, but to me this problem they’re trying to solve, has already been solved. Singularity ‘requires’ root or elevated privileges to create and modify containers, Well, Singularity came out at the same time as runc's rootless containers support was developed -- so at the time it wasn't solved at all. It required (and still requires for several operations and features) root privileges in order to work (such as suid helpers in addition to explicit root requirements). It's not acceptable for a usecase where you cannot run anything as root (not even installation scripts). That was the use-case, and rootless runc (and now thanks to Akihiro and Guiseppe, rootless Docker and Kubernetes) in theory can now work without the need for any suid helpers -- though these days there is an increasing usage of newuidmap and newgidmap (which isn't mandated for the rootless runc implementation). At the time, LXC's unprivileged containers was the closest thing and it had a few (mostly optional) suid binaries -- I wanted absolutely none. > but running them is done in the user’s namespace with that user’s permission set. And privileges can’t be elevated during the containers runtime as there are kernel level catches that prevent sudo and su from working inside the container. This last part really isn't revolutionary at all. All it really takes is a syscall and three files to write to. The hard part is getting everything else to work without root privileges.

mroche 8y ago
Are you a dev on binctr? Is so, the following statements are based off an assumption of yes. > Well, Singularity came out at the same time as runc's rootless containers support was developed -- so at the time it wasn't solved at all. It required (and still requires for several operations and features) root privileges in order to work (such as suid helpers in addition to explicit root requirements). Alright, but I wasn’t asking about a “back then” scenario, I was mostly trying to figure out what this offers _today_. From a Singularity end-user’s perspective, there’s only one function that requires elevated permissions, and that’s building. > It's not acceptable for a usecase where you cannot run anything as root (not even installation scripts). ... At the time, LXC's unprivileged containers was the closest thing and it had a few (mostly optional) suid binaries -- I wanted absolutely none. Now I understand what this offers and it’s overarching goal is. In my specific situation (which is the angle I’m looking at this from), that’s not really a big deal due to the way we handle global and local software installation. I understand this is not a universal situation. > This last part really isn't revolutionary at all. I don’t think I made it sound like it was revolutionary, I was just sharing what a commonly used tool in HPC does for a security measure. Based off of the binctr README: > Create fully static, including rootfs embedded, binaries that pop you directly into a container. _Can be run by an unprivileged user._ My main confusion stems from that. In comparison to Singularity, it doesn’t seem to offer anything new or noteworthy that would make me take a second look at it. The first phrase just makes me think I’m saving myself a few keystrokes as I wouldn’t have to type `singularity shell <container>` to shell into my container of choice. It just looks like yet another container solution. I still find these things cool (and their above my head in dev terms), but it feels like programming languages, a new one popping up every so often. I’m primarily looking to see what advantages (or differences in approach) this offers over Singularity, Shifter, or Charliecloud, etc for my context. At least in terms of security and efficiency.