3 ms·

> Are you a dev on binctr? No, but I'm a maintainer of runc and implemented all of the core features that binctr uses (or rather, that Jessie hacked together f

by cyphar 8y ago

> Are you a dev on binctr? No, but I'm a maintainer of runc and implemented all of the core features that binctr uses (or rather, that Jessie hacked together for a proof of concept). I've also implemented rootless support in quite a few other tools to the point where now an unprivileged user can download, extract, and run a rootless container. In addition, I'm working with some other folks who joined later to get Kubernetes (and Docker) to be completely rootless. > From a Singularity end-user’s perspective, there’s only one function that requires elevated permissions, and that’s building. (Most forms of) execution still requires setuid binaries, which means that you have to have root permissions in order to install Singularity. You can use rootless containers as a completely unprivilged user (meaning that if you have unprivileged shell access to a random box you can use containers). Singularity cannot do this. > I was just sharing what a commonly used tool in HPC does for a security measure. My point was that basically any container runtime can do what you described. > 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. Many of those tools require setuid binaries that are developed as part of their container runtime -- which means that all of the security is contingent in no vulnerabilities in their setuid binaries (something that is hard to do even for the developers of programs like sudo). Rootless containers are a project that requires absolutely no privileged codepaths for any container operation (though these days you can optionally use standard setuid binaries -- by default they are not used). This is something that none of the projects you listed (as far as I'm aware) can do.

gnufx 8y ago
Thanks for piping up. Charliecloud specifically doesn't require setuid, but many HPC systems won't have user namespaces enabled. (It removed the setuid component which allowed it to work on RHEL6, for instance.) You can also easily build a root for it under proot, for instance -- and proot itself is probably OK for running computationally-intensive work. HPC systems already have a privilege escalation mechanism available from the resource manager, but I don't know there's a problem using it for this sort of thing. Shifter controls the images, so you're not at risk from malformed filesystems, at least. Definitely setuid in Singularity should worry people. It has a non-stellar security record, and has been less than transparent about issues. The last time I looked at the code for instance it still had many calls unchecked for error returns (including all mallocs), and wrote uninitialized memory to image files. It was a mistake to get it into Fedora, and HPC people should be a bit more circumspect. That said, resource managers probably provide most attack surface in HPC systems, in some case completely trivially. By the way, it's often possible just to run programs from an unpacked filesystem of another distribution just by setting PATH and LD_LIBRARY_PATH.
- mroche 8y ago
  Not sure when you last looked at Singularity's code base, but it was completely re-written this year into Go, so some of the issues you saw may have been solved. Not sure, just letting you know if you haven't been following its development. > It was a mistake to get it into Fedora, and HPC people should be a bit more circumspect. I never installed it from EPEL, as building from source was relatively easy in 2.x (trivially easy in 3.x) and allowed buildtime configurations specific to a cluster. If you pay for support you get custom repos, but that's up to the cluster maintainers to decide.
  - gnufx 8y ago
    I know it's been re-written, but I don't know why that would restore my faith in it and Sylabs (for multiple reasons). It emphasizes the point about inclusion in Fedora (and other distributions?) for which there's some expectation of security and stability, even if you don't care about that.

by cyphar 8y ago

gnufx 8y ago

Thanks for piping up. Charliecloud specifically doesn't require setuid, but many HPC systems won't have user namespaces enabled. (It removed the setuid component which allowed it to work on RHEL6, for instance.) You can also easily build a root for it under proot, for instance -- and proot itself is probably OK for running computationally-intensive work. HPC systems already have a privilege escalation mechanism available from the resource manager, but I don't know there's a problem using it for this sort of thing. Shifter controls the images, so you're not at risk from malformed filesystems, at least. Definitely setuid in Singularity should worry people. It has a non-stellar security record, and has been less than transparent about issues. The last time I looked at the code for instance it still had many calls unchecked for error returns (including all mallocs), and wrote uninitialized memory to image files. It was a mistake to get it into Fedora, and HPC people should be a bit more circumspect. That said, resource managers probably provide most attack surface in HPC systems, in some case completely trivially. By the way, it's often possible just to run programs from an unpacked filesystem of another distribution just by setting PATH and LD_LIBRARY_PATH.

mroche 8y ago
Not sure when you last looked at Singularity's code base, but it was completely re-written this year into Go, so some of the issues you saw may have been solved. Not sure, just letting you know if you haven't been following its development. > It was a mistake to get it into Fedora, and HPC people should be a bit more circumspect. I never installed it from EPEL, as building from source was relatively easy in 2.x (trivially easy in 3.x) and allowed buildtime configurations specific to a cluster. If you pay for support you get custom repos, but that's up to the cluster maintainers to decide.
- gnufx 8y ago
  I know it's been re-written, but I don't know why that would restore my faith in it and Sylabs (for multiple reasons). It emphasizes the point about inclusion in Fedora (and other distributions?) for which there's some expectation of security and stability, even if you don't care about that.