51–60 of 87 posts
Julia Evans has an excellent zine on how containers work, including a 15-line bash implementation: https://jvns.ca/blog/2020/04/27/new-zine-how-containers-work... Definitely worth the $12.
You can download it for free too: https://gumroad.com/l/containers-zine/buyonegiveone
There is an official option to either pay or get it for free. Do support her if you can.
A little bit of education about container systems in linux[1]. A container system is typically made up a number of components: isolation layer : the piece that limits privileges and resource usage. (On linux, this is usually handled by cgroups and the kernel, but could also be handled by something like kvm for vm-based containers) raw container configuration : Given an image and some metadata (like cpu limits), launc…
I feel like podman is proving that you don't really need the api daemon and a porcelain over runc with a one-off process supervisor is sufficient for a good number of workloads. Being able to run containers like any other process and leave the lifecycle management to systemd is actually really nice.
With stuff like RootImage and the various isolation settings you can have a configurably sandboxed container right in systemd.
Or just use systemd-nspawn if you want it more preconfigured.
Earlier quoted context omitted.
Big “if”. There has never, in thirty years, been a Linux that lacked a user-to-root privilege escalation path. Running untrusted code in containers is the same as it’s ever been: totally unsafe. VMs are safer, or, minimally, ptrace sandboxes intercepting all syscalls.
Are you saying because of bugs or are you saying it's by design? I explicitly said ignore OS bugs.
Earlier quoted context omitted.
I'm not sure if this is serious or a joke, but can you explain it further?
Given certain initial conditions, this statement moves the current process (and any process it subsequently creates) into a control group, which meets minimal definitions of containerization.
$ mkdir /dev/cpuset
$ mount -t cpuset cpuset /dev/cpuset
$ cd /dev/cpuset
$ mkdir Charlie
$ cd Charlie
$ /bin/echo 2-3 > cpuset.cpus
$ /bin/echo 1 > cpuset.mems
$ /bin/echo $$ > tasks
# The current shell is now running in cpuset Charlie
# The next line should display '/Charlie'
$ cat /proc/self/cpuset
A little bit of education about container systems in linux[1]. A container system is typically made up a number of components: isolation layer : the piece that limits privileges and resource usage. (On linux, this is usually handled by cgroups and the kernel, but could also be handled by something like kvm for vm-based containers) raw container configuration : Given an image and some metadata (like cpu limits), launc…
Clarification: cgroups only control access to compute resources, like CPU time and memory. To control privileges, e.g. access to the filesystem or network, you need namespaces, which are a completely separate kernel feature.
Big caution here. Do NOT use this style of code to invoke ip tools. This was the cause of a huge number of security vulnerabilities on Android in the first few years. Even if you're hardcoding interfaces to start, it's likely someone else will drive by later on and replace one of the args with %s. > system("ip link add veth0 type veth peer name veth1"); Always, always, always use exec*() APIs.
Could someone comment on how secure such a container is, at least nominally? Should I be able to theoretically run untrusted code on such a container if the system is bug-free and I add proper error-checking to the code? Or are there things that you'd need to worry about the code being able to access? Any considerations regarding sudo permissions?
Big “if”. There has never, in thirty years, been a Linux that lacked a user-to-root privilege escalation path. Running untrusted code in containers is the same as it’s ever been: totally unsafe. VMs are safer, or, minimally, ptrace sandboxes intercepting all syscalls.
Emulating an entire machine, all of its diverse hardware, their bespoke protocols, and all the weirdness of the x86/amd64 ISA is fraught with peril. It is a large attack space. So too is the Linux kernel.
And frankly, inside the VM, half of us are running Linux anyways. I feel like for a lot of use cases, compromising the VM's guest OS (Linux) is enough to have a really bad day. Compromising the hypervisor? Bad, yes, but now it's AWS's problem.
There's more to containers, too, than just the security thing, and I think there are enough other advantages (I can more easily bin-pack services together; I can separate the FS and thus dependencies of unrelated components; I can more easily test them; etc.) that containers are worth it. Often and even on top of a VM. (My current work is with containers, and we run them on VMs.)
Big caution here. Do NOT use this style of code to invoke ip tools. This was the cause of a huge number of security vulnerabilities on Android in the first few years. Even if you're hardcoding interfaces to start, it's likely someone else will drive by later on and replace one of the args with %s. > system("ip link add veth0 type veth peer name veth1"); Always, always, always use exec*() APIs.
Are there not better C APIs to call that `ip` et al are wrapping?
Big caution here. Do NOT use this style of code to invoke ip tools. This was the cause of a huge number of security vulnerabilities on Android in the first few years. Even if you're hardcoding interfaces to start, it's likely someone else will drive by later on and replace one of the args with %s. > system("ip link add veth0 type veth peer name veth1"); Always, always, always use exec*() APIs.
Are there not better C APIs to call that `ip` et al are wrapping?