Hacker News Reader

Comment by tliltocatl | Hacker News Reader

Containers and namespaces are not about security. They are about not having singleton objects at the OS level. Would have called it virtualization if the word wasn't so overloaded already. There is a big difference that somehow everyone misses. A bypassable security mechanism is worse than useless. A bypassable virtualization mechanism is useful. It is useful to be able to have a separate root filesystem just for this program - even if a malicious program is still able to detect it's not the true root.

As about SEL4 - it is so elegant because it leaves all the difficult problems to the upper layer (coincidentally making them much more difficult).

View on HN

> Containers and namespaces are not about security

True. Yet containers, or more precisely the immutable images endemic to container systems, directly address the hardest part of application security: the supply chain. Between the low effort and risk entailed when revising images to address endlessly emerging vulnerabilities, and enabling systematized auditing of immutable images, container images provide invaluable tools for security processes.

I know about Nix and other such approaches. I also know these are more fragile than the deeply self-contained nature of containers and their images. That's why containers and their image paradigm have won, despite all the well-meaning and admirable alternatives.

> A bypassable security mechanism is worse than useless

Also true. Yet this is orthogonal to the issues of supply chain management. If tomorrow, all the problems of escapable containers were somehow solved, whether by virtual machines on flawless hypervisors, or formally verified microkernels, or any other conceivable isolation mechanism, one would still need some means to manage the "content" of disparate applications, and container systems and the image paradigm would still be applicable.

> I also know these are more fragile than the deeply self-contained nature of containers and their images

Not really. People only use Nix because it doesn't randomly break, bitrot or require arcane system setup.

Unlike containers. You really need k8s or something like it to mould Docker containers into something manageable.

Containers don't break in any of those ways, but rebuilding the images with updates does and the same is entirely true of nix.

No, because Nix configuration is declarative and statically checked.

Containers is "run these random shell commands I copy pasted from the internet on top of this random OS image I pulled from the internet, #yolo".

Did you inspect the build code of all the nixpkgs you imported? Did you inspect the code of the tarballs they depend on? Sure, the SHA256 is right there...did you look at it?

People copy and paste nix code all the damn time because it's downright unparseable and inscrutable to the majority of users. Just import <module>, set some attrs and hit build. #yolo

Nix code is composable and statically checked for consistency. Docker containers is just a random sequence of shell scripts that sometimes happens to not error out because people mostly only use the same five Ubuntu or Alpine base images and don't layer more than two things at once.

You see the difference?

> People only use Nix because it doesn't randomly break, bitrot or require arcane system setup.

I'll stipulate this, despite knowing and appreciating the much greater value Nix has.

Then, the problem that Nix solves isn't something container users care about. At scale, the bare metal OS hosting containers is among the least of one's problems: typically a host image is some actively maintained, rigorously tested artifact provided by one of a couple different reliable sources. Ideally container users are indifferent to it, and they experience few if any surprises using them, including taking frequent updates to close vulnerabilities.

> Unlike containers.

Containers randomly break or bitrot? I've never encountered that view. They don't do this as far as I'm aware. Container images incorporate layer hashing that ensure integrity: they do not "bitrot." Image immutability delivers highly consistent behavior, as opposed to "randomly break." The self-contained nature of containers delivers high portability, despite differences in "system setup." I fail to find any agreement with these claims. Today, people think nothing of developing images using one set of tools (Docker or what have you) and running these image using entirely distinct runtimes (containerd, cloud service runtimes, etc.) This is taken entirely for granted, and it works well.

> Arcane system setup.

I don't know what is meant by "system setup" here, and "arcane" is subjective. What I do know is that the popular container systems are successfully and routinely used by neophytes, and that this doesn't happen when the "system setup" is too demanding and arcane. The other certainty I have is that whatever cost there is in acquiring the rather minimal knowledge needed to operate containers is vastly smaller than achieving the same ends without containers: the moment a system involves more than 2-3 runtime components, containers start paying off verses running the same components natively.

> Containers randomly break or bitrot?

All the fucking time. Maybe it's possible to control your supply chain properly with containers, but nobody actually does that. 99% of the time they're pulling in some random "latest image" and applying bespoke shell commands on top.

> I don't know what is meant by "system setup" here, and "arcane" is subjective.

Clearly you've never debugged container network problems before.

> but nobody actually does that

They do. I assure you.

> they're pulling in some random "latest image"

Hardly random. Vendoring validated images from designated publishers into secured private repos is the first step on the supply chain road.

> Clearly you've never debugged container network problems before.

Configuring Traefik ingress to forward TCP connections to pods was literally the last thing I did yesterday. At one time or another I've debugged all the container network problems for every widely used protocol in existence, and a number of not so common ones.

> first step on the supply chain road

99 percent of Docker container users aren't on the supply chain road. They just want to "docker pull", #yolo.

> Configuring Traefik ingress to forward TCP connections to pods was literally the last thing I did yesterday

Docker does crazy insane modifications to your system settings behind the scenes. (Of which turning off the system firewall is the least crazy.)

Have fun when the magic Docker IP addresses happen to conflict with your corporate LAN.

Feel free to have whatever problems you enjoy with Docker and its users. The discussion was about containers and their security, reliability and usability, and there I haven't found one thing you've written that made any sense. Your conflation of Docker with all of this is a strong clue that your actual knowledge on the topic is limited.

> As about SEL4 - it is so elegant because it leaves all the difficult problems to the upper layer (coincidentally making them much more difficult).

I completely buy this as an explanation for why SEL4 for user environments hasn't (and probably will never) take off. But there's just not that much to do to connect a server application to the network, where it can access all of its resources. I think a better explanation for the lack of server side adoption is poor marketing, lack of good documentation, and no company selling support for it as a best practice.

The lack of adoption is because it’s not a complete operating system.

Using sel4 on a server requires complex software development to produce an operating environment in which you can actually do anything.

I’m not speaking ill of sel4; I’m a huge fan, and things like it’s take-grant capability model are extremely interesting and valuable contributions.

It’s just not a usable standalone operating system. It’s a tool kit for purpose-built appliances, or something that you could, with an enormous amount of effort, build a complete operating system on top of.

Yes. I really hope someone builds a nice, usable OS with SeL4 as a base. If SeL4 is like the linux kernel, we need a userland (GNU). And a distribution that's simple to install and make use of.

I'd love to work on this. It'd be a fun problem!

seL4 needs a ‘the rest of the kernel’ to be like linux

It needs device drivers for modern x86 hardware. And filesystems, and a TCP stack. All of that code can be done in "SeL4 userland", but yeah - I see your point.

Are there any projects like that going on? It feels like an obvious thing.

A lot of deployments essentially virtualize Linux or run portions of NetBSD (e.g. via their "rump" kernel mechanism) to achieve driver support, file systems, etc. That's not really a general-purpose solution, though.

There is work within major consumer product companies building such things (either with sel4, or things based on sel4's ideas), and there's Genode on seL4.

Are you aware of https://genode.org ?

> But there's just not that much to do to connect a server application to the network, where it can access all of its resources.

If you only care to run stateless stuff that never write anything (or at least never read what they wrote) - it's comparatively easy. Still gotta deal with the thousand drivers - even on the server there are a lot of quirky stuff. But then you gotta run the database somewhere. And once you run a database you get all the problems Linus warned about. So you gotta run the database on a separate Linux box (at that point - what do you win vs. using Linux for everything?) or develop a new database tailored for SeL4 (and that's quite a bit more complex than an OS kernel). An elegant solution that only solves a narrow set of cases stands no chance over a crude solution that solves every case.

Also, with the current sexy containerized stacks it's easy to forget, but having same kind of environment on the programmer's workbench and on the sever was once Unix's main selling point. It's kinda expensive to support a separate abstraction stack for a single purpose.

> A bypassable security mechanism is worse than useless

Looks like the Nirvana fallacy.

> Containers and namespaces are not about security

An escape from properly configured container/namespaces is a kernel 0day. Or a 0day in whatever protocol the isolated workload talks to the outside with.

> Containers and namespaces are not about security

People keep saying that, but I do not get it. If an attack that would work without a container, fails from inside a container (e.g. because it cannot read or write a particular file, or it cannot) it is better security.

> A bypassable security mechanism is worse than useless.

It needs the bypass to exist, and it needs an extra step to actually bypass it.

Any security mechanism (short of air gaps) might have a bypass.

> even if a malicious program is still able to detect it's not the true root.

Also true for security unless it can read or write to the true root.

You can use containers as a security measure, but I'd argue that if (when) it fails in a spectacular way (see e. g. abstract sockets for an interesting past issue) it's your fault and not a zero-day in the kernel as a sibling comment suggest. To put it a bit less harsh - containers are not just for security and containerization tools have to balance security vs usability.

Yes, I do not think we disagree much.

I use containers as an extra security measure. i.e. as a way of reducing the chance that a compromise of one process will lead to a compromise of the rest of the system.

That said, I would guess that providers of container hosting must be fairly confident that they can keep them secure. I do not know what extra precautions they take though.

Reply on news.ycombinator.com