6 ms·

From a previous discussion: One very interesting piece of tech coming from podman, is toolbox (https://github.com/containers/toolbox https://github.com/contain

• nickstinemates 5y ago
  Sounds like a chroot with extra steps
  • detaro 5y ago
    That's a way to describe pretty much all container things in a superficial way.
    • scatters 5y ago
      It's not even superficial. A chroot is a limiting case of a container that only rebinds the filesystem; or, equally, a container is a chroot that also rebinds the user namespace, process namespace, networking, etc.
      • yakubin 5y ago
        Can you escape from a mount namespace? You can escape from a chroot.
        • majewsky 5y ago
          You can change into an existing mount namespace, which is what commands like "docker exec" or "machinectl shell" do to execute a command within the mount namespace of an existing container. The container can do the same to escape its mount namespace, but it needs privileges to execute the respective namespace-changing syscall, and it needs to know which namespace to change into. I have an application in a Kubernetes-managed container which needs to do exactly this to access the host system (to open LUKS containers and mount their contents), so I have it run in privileged mode (i.e. with access to all syscalls) and give it the full host filesystem as a bind mount, so it can do: nsenter -m /host/proc/1/ns/mnt mount $DEV $PATH (The actual nsenter invocation is slightly more complicated, but that's the basic gist.) Side-note: Since there will inevitably be a comment along the lines of "but then what do you even need isolation for", I'm very explicitly using Kubernetes as a deployment mechanism only. Other pods within the same Kubernetes are strictly isolated, but this one deliberately runs with practically no isolation. But I still get the consistent environment that Kubernetes provides (rolling upgrades, log shipping, liveness probes, etc.).
  • silisili 5y ago
    I know this was made tongue in cheek, but that was my first thought as well. Seems it would be more valuable for one to explain how and why it's better than a chroot, instead of redescribing how a chroot works but adding the word container.
    • cpach 5y ago
      Some pointers if anyone is curious about chroot vs other isolation techniques: https://fly.io/blog/sandboxing-and-workload-isolation/ https://fly.io/blog/sandboxing-and-workload-isolation/ https://devops.stackexchange.com/questions/2826/difference-between-chroot-and-docker https://devops.stackexchange.com/questions/2826/difference-b... For further reading, searching for ⟬docker vs chroot⟭ yields a bunch of interesting articles.
    • bjt 5y ago
      chroot just isolates the file system. A "container" (whether Docker or LXC or Podman) is a bundle of isolations that includes the filesystem as well as processes and users, and constraints on memory, CPU, networking, and kernel calls.
      • chriswarbo 5y ago
        AFAIK Docker, LXC, Podman, etc. are actually all the same underneath: they use 'runc', which chroots into a directory (along with extra restriction/config via cgroups, bind mounts, etc.). The differences between Docker, LXC, Podman, etc. are the config, management, etc. of containers; e.g. Docker abstracts over the chroot directories, using a set of content-addressed tarballs (called "images"), and provides commands for starting/stopping/listing/etc. the containers that are running.
        • bjt 5y ago
          Dating myself a little, but LXC came along well before runc. It predates Docker, and was actually wrapped by the first versions of Docker. I learned about LXC, and used it, after doing some research on how to build my own PaaS at work (pre-Docker) and reading that Heroku was using LXC for their platform. It worked decently for me, but required more in-depth knowledge of all the knobs for disk mounts and networking than Docker typically requires. You may be right that LXC has switched over to runc since then. I haven't kept up. I would be surprised though.
• EnigmaCurry 5y ago
  I've been using rootless podman containers for several years, but I've stopped using them recently. I read this security note on the Arch wiki [1]: > Warning: Rootless Podman relies on the unprivileged user namespace usage (CONFIG_USER_NS_UNPRIVILEGED) which has some serious security implications, see Security#Sandboxing [2] applications for details. Accordingly, I've since set sysctl `kernel.unprivileged_userns_clone` to `0` on my system which disables rootless containers, but is now supposedly safer. The dialog on this is a bit controversial, it seems rootless podman is pardoxically both more secure and less secure at the same time. Rootless podman doesn't have root access, but with user namespaces turned on, podman has access to kernel apis that have not been rigorously tested for non-root users. Someone explained this on Security SO a bit more in depth [3]: > The reason for this is that much of the kernel that is only intended to be reachable by UID 0 is not audited particularly well, given that the code is typically considered to be trusted. That is, a bug that requires a UID of 0 is rarely considered a serious bug. Unfortunately, unprivileged user namespaces make it possible for unprivileged users to access this very same code and exploit security bugs. [1] https://wiki.archlinux.org/title/Podman#Rootless_Podman https://wiki.archlinux.org/title/Podman#Rootless_Podman [2] https://wiki.archlinux.org/title/Security#Sandboxing_applications https://wiki.archlinux.org/title/Security#Sandboxing_applica... [3] https://security.stackexchange.com/a/209533 https://security.stackexchange.com/a/209533
  • chousuke 5y ago
    I'm not sure what the tradeoff is. You can give a user access to rootless containers or you can give them root access to run containers. User namespaces are at least attempting to improve on the Docker situation where access to the Docker daemon is effectively equivalent to root access, unless that has changed recently. Does the exposed kernel surface actually extend to the processes running in the contained environment?
    • kbenson 5y ago
      I think the problem might be in the interplay of how many allications/daemons already try to drop privileges by running as a user after doing the few things they need those privileges for (like binding to a low port), and if you don't even need those privileges, you don't even need to start it as root, and your container has well known security properties. If you're running rootless and using namespaces to allow non-root users access to previously root-only kernel APIs, then a bunch of prior assumptions may no longer hold, and there's a new attack space available to target that has always existed, but was of no use previously to exploit.
• stavros 5y ago
  Oh damn, I love this, thank you! EDIT: Looks like they don't provide either an Ubuntu/Debian executable or an Ubuntu root image, which is a bit unfortunate. Odd that someone would make a project and ignore the most common Linux distro...
  • runfalk 5y ago
    It's pretty easy to create one yourself (from an open MR https://github.com/containers/toolbox/pull/483/files#diff-21a4a6cd917517fc7f7dd1c4ab028a75d2457cdf1bb6d077eaf2f82977766eab https://github.com/containers/toolbox/pull/483/files#diff-21...), but it would have been nice to have out of the box. I've used buildah to set up a C/C++ dev environment in a Ubuntu toolbox at work without any major issues.
  • raesene9 5y ago
    IME podman is optimized for use in Redhat based environment. I've had a couple of odd problems when trying to use it on Debian/Ubuntu. It's not surprising given it's a Redhat project, but it does put me off using it as I'm most comfortable with debian derived environments.
    • deleted 5y ago
      [deleted]
• remram 5y ago
  This sounds exactly like Singularity http://singularity.hpcng.org/ http://singularity.hpcng.org/
• nonameiguess 5y ago
  I get why the pithy "chroot with more steps" comment has been largely dismissed, but when all you're going for is the temporary installation of build dependencies without impacting the permanent system, chroot really can do enough. The other stuff with user namespaces to isolate process IDs, networks, and map UIDs to get root in the user namespace without actually being root, aren't strictly needed. There is an Arch Linux devtools project providing some shell scripts to automate setting up clean build chroots, but they're of course focused on setting up an isolated Arch system, and still require running as root. The true poor man's way to do this without being root is to use fakeroot and fakechroot, which is what the Debian builds do. The examples from Debian would all run debootstrap to set up a minimal Debian in the chroot, but you can just run "fakeroot fakechroot <any command>" to use your own build tools and bootstrap your own build environment. That way you don't even require a container runtime and don't need to open up the attack surface of user namespaces.
  • chriswarbo 5y ago
    Along the same likes as fakeroot/fakechroot, I've found proot to be super useful for writing startup scripts for commands which make awkward assumptions about the filesystem layout.
• otabdeveloper4 5y ago
  So they reinvented Nix except badly? (Eventually people will come around to the Nix model. Especially because it's, essentially, like what happens when you install apps on phones.)
  • 3np 5y ago
    Apart from that both can be used for sandboxing/isolation, I see no similarities between the two.