3 ms·

I think pledge (and unveil) are really good ideas, but that doesn't mean it's a substitute for containers. They're kind of different: pledge mostly just enforce

I think pledge (and unveil) are really good ideas, but that doesn't mean it's a substitute for containers. They're kind of different: pledge mostly just enforces correctness of a program, whereas containers enforce separation. I think containers are more analogous to privsep (used extensively in OpenBSD) than pledge. My biggest issue with the current state is that the common tools (e.g. Docker, k8s) are pretty terrible. Docker overcomplicates a great many things, which is one reason for the many bugs. And k8s ... well, let's not even go there. I don't think much more is needed than just `run-container /usr/containers/cool-container` and presto, a container with the files in that directory. No need for buggy/slow platform-dependent FS abstraction layers that change every year because they never quite work right in a bazillion edge cases. This is how e.g. FreeBSD jails work. This won't prevent implementing tools like `docker pull`; at it simplest it could be `curl ... | tar xf - -C /usr/containers/cool-container`. Running multiple containers based of a single image? `cp -r`. Maybe I'm just an old Unix guy, but I think that composition from generic tools is a much better approach for a lot of this stuff. It's easier, less platform-dependent, has less code (meaning less bugs), etc.

nwmcsween 8y ago
Containers are basically a few syscalls wrapped in a ball of mud, pledge is containment and the Linux somewhat broken and ugly alternative seccomp bpf is used in most containers _but_ not properly as most containers are bundles of software (multiple binaries) which makes it hard to contain a container (ha) as you have to allow more syscalls than needed. A better way would just use .preinit_array and inject a .seccomp section, .unshare, etc to create per binary containment or just chain-load everything in one big line.
- Carpetsmoker 8y ago
  > Containers are basically a few syscalls wrapped in a ball of mud I don't think it has to be; I mean, the current Linux/Docker situation is kind of that, but that's just a single implementation. > most containers are bundles of software (multiple binaries) Yeah, exactly. Containers aren't just about security, also convenience. Something like "docker pull someimage" can be a handy cross-platform way to run stuff. I think "docker pull" is the reason for Docker's popularity. You can build a self-contained container containing Ruby, all your Ruby on Rails stuff and JS stuff, and whatnot, and then send that to any server and just "docker run" it. Getting some of this dynamic stuff to run can be tricky and error-prone: need to get the correct Ruby version, Rails version, muck about with bundle, etc. Want to add a new app-server or migrate to somewhere else? Need to spend a day setting everything up again and hope you didn't make a mistake that will bite you later :-( A self-contained container is a lot easier, even with good OS package management or automation tools like Puppet. Many people also use Docker as "Vagrant" (e.g. to run dev versions or tests and whatnot). Again, "docker pull" is convenient here, especially when there are certain dependencies/requirements, or for running testing against different versions of some dependency, etc. Again, I don't think Docker is very good as such, but I do think there are some ideas worth keeping, both for security and plain convenience (not often those two go hand-in-hand!)

nwmcsween 8y ago

Containers are basically a few syscalls wrapped in a ball of mud, pledge is containment and the Linux somewhat broken and ugly alternative seccomp bpf is used in most containers _but_ not properly as most containers are bundles of software (multiple binaries) which makes it hard to contain a container (ha) as you have to allow more syscalls than needed. A better way would just use .preinit_array and inject a .seccomp section, .unshare, etc to create per binary containment or just chain-load everything in one big line.

Carpetsmoker 8y ago
> Containers are basically a few syscalls wrapped in a ball of mud I don't think it has to be; I mean, the current Linux/Docker situation is kind of that, but that's just a single implementation. > most containers are bundles of software (multiple binaries) Yeah, exactly. Containers aren't just about security, also convenience. Something like "docker pull someimage" can be a handy cross-platform way to run stuff. I think "docker pull" is the reason for Docker's popularity. You can build a self-contained container containing Ruby, all your Ruby on Rails stuff and JS stuff, and whatnot, and then send that to any server and just "docker run" it. Getting some of this dynamic stuff to run can be tricky and error-prone: need to get the correct Ruby version, Rails version, muck about with bundle, etc. Want to add a new app-server or migrate to somewhere else? Need to spend a day setting everything up again and hope you didn't make a mistake that will bite you later :-( A self-contained container is a lot easier, even with good OS package management or automation tools like Puppet. Many people also use Docker as "Vagrant" (e.g. to run dev versions or tests and whatnot). Again, "docker pull" is convenient here, especially when there are certain dependencies/requirements, or for running testing against different versions of some dependency, etc. Again, I don't think Docker is very good as such, but I do think there are some ideas worth keeping, both for security and plain convenience (not often those two go hand-in-hand!)