Earlier quoted context omitted.
Sandstorm has had a pretty good track record [1]. Then again, it was designed and run by capability security folks, who take security pretty seriously. [1] https://sandstorm.io/
Unfortunately it is shutting down.
Containers in 2019: They're Calling It a Hypervisor Comeback
111–120 of 196 posts
Re: Containers in 2019: They're Calling It a Hypervisor Comeback
#112Earlier quoted context omitted.
What I’ve always failed to Understand is how FreeBSD jails[0] never got very popular (discounting the fact that FreeBSD isn’t very popular on the whole from what I can tell) but Docker is huge. I personally think jails are superior in implementation in that it requires no other abstractions on top of the OS. The only thing I can surmise is that Docker might have a better secure default, but improvements to Jails coul…
This happened because docker, in addition to an isolation system, also bundled a user friendly interface to a per-app persistent filesystem. No matter how many people sing the praises of isolation and security to Docker, I will continue to suspect that almost all of its adopters use it because packaging software with dependencies is hard, poorly understood, terribly tooled (looking at you, Python), and even more poor…
Re: Containers in 2019: They're Calling It a Hypervisor Comeback
#113I've had this sneaking but hard to articulate suspicion that datacenters, bare metal servers, VMs, operating systems, containers, OS processes, language VMs, and threads are all really attempts to abstract the same thing. You want to run business code in a way that's protected from other business code but also able to interact with other business code and data in a well defined way. I also have this sneaking suspicio…
There is a very easy way to articulate it: they are all ways of virtualizing different facilities. Unix processes virtualize the user-mode processor registers and the address space. POSIX threads only virtualize the processor registers and the stack. Linux namespaces let you pick and choose which facilities you want to virtualize (storage, PID namespace, IPC namespace, etc.).
The abstraction is related to what is being virtualized: everything that is virtualized is a namespace (this is what naming things refers to in Phil Karlton's quote "There are only two hard things in Computer Science: cache invalidation and naming things," not to the literal naming of variables in computer programs).
Another way to go instead of virtualization is capabilities.
Re: Containers in 2019: They're Calling It a Hypervisor Comeback
#114I've had this sneaking but hard to articulate suspicion that datacenters, bare metal servers, VMs, operating systems, containers, OS processes, language VMs, and threads are all really attempts to abstract the same thing. You want to run business code in a way that's protected from other business code but also able to interact with other business code and data in a well defined way. I also have this sneaking suspicio…
Re: Containers in 2019: They're Calling It a Hypervisor Comeback
#115Earlier quoted context omitted.
What I’ve always failed to Understand is how FreeBSD jails[0] never got very popular (discounting the fact that FreeBSD isn’t very popular on the whole from what I can tell) but Docker is huge. I personally think jails are superior in implementation in that it requires no other abstractions on top of the OS. The only thing I can surmise is that Docker might have a better secure default, but improvements to Jails coul…
Docker is convenient. You can just download the docker binary and type "docker run postgres" and have a container running Postgres. What's the equivalent for FreeBSD jails?
Re: Containers in 2019: They're Calling It a Hypervisor Comeback
#116Earlier quoted context omitted.
> You need docker to handle the DNS, routing, port forwarding etc. If you do IPv6, there is no need for all of these layers of IPv4 overlay network crap.
IPv6 saves you from setting up DNS on each instance and will do load balancing?
Re: Containers in 2019: They're Calling It a Hypervisor Comeback
#117Re: Containers in 2019: They're Calling It a Hypervisor Comeback
#118Earlier quoted context omitted.
> ...preventing devs/ops people to run tools like This is because docker makes the fundamental mistake of conflating packaging with isolation. "Packaging" is achieved in docker by using the OS to do an amount of sandboxing and then letting the user perform whatever non-reproducible crap they like before balling the whole thing up and calling it a package. If instead you make an app author actually figure out what the…
So a system like Android's? Honest question, I don't know of that's a good model to exist in general purpose Linux systems. There's also Fuchsia but I'm not sure if it's POSIX.
Not really, I'm essentially describing nix/guix.
Re: Containers in 2019: They're Calling It a Hypervisor Comeback
#119I see container systems, such as Docker, as a packaging system more than anything else.
A Turing complete, language agnostic one. If you were trying to write one that wasn’t container focused, how would that look?
Containers are a very poor substitute for package managers.
Re: Containers in 2019: They're Calling It a Hypervisor Comeback
#120I've had this sneaking but hard to articulate suspicion that datacenters, bare metal servers, VMs, operating systems, containers, OS processes, language VMs, and threads are all really attempts to abstract the same thing. You want to run business code in a way that's protected from other business code but also able to interact with other business code and data in a well defined way. I also have this sneaking suspicio…
Because current model of processes frankly sucks. If I give you random binary would you run it? You can talk about sandboxing, lecture about permissions and principles of least privilege. But that still doesn't answer the question: can it run hostile code without having side effects on the rest of the system? Other than the newer web tech initiatives like WebAssembly/JS sandboxing, there do not exist any other techno…
Yes, this is the lightest weight isolation that's somewhat secure for random code.. And considering that we regularly find exploits that escape that sandbox, I would never use it to run some random persons code on a server. Yes, we do that all the time in the browser, but that's a more limited environment where a single user is choosing what to run... whereas on a server, anyone who wants to attack the service can just upload whatever code they want.
I know Cloudflare is doing it in Cloudflare Workers... and I think that's crazy. They're inspecting the code, and they added OS sandboxing... so that's a little better.. but trusting the JS sandbox in that environment is just nuts. Wouldn't surprise me if this ended up being another cloudbleed.
If you want to run random code, the only safe option right now is to use a heavier form of isolation like a VM (and even that is not perfect). The performance loss is the necessary trade off to allow random people to run code (some of whom are deliberately attacking the service). This is the downside to the "cloud"... performance losses to allow random people to share servers.