> it is your responsibility to know how the components you choose work and how much you can rely on them

Unfortunately that is not always your choice and arguing against it most commonly costs you more than you like. My experience is quite often timelines get underestimated massively with software so you end up doing what you can with the resources given. If you pull this into the bridge metafore the bridge still stands but can collapse any time and as long as it doesn't collapse during rush hour and can be rebuilt before the next morning it's all fine.

Yep, this is accurate. People making decisions often value “works”/“ships” more than “secure” and the time allocations reflect it.

I wish it wasn’t the case, but it is.

It's pragmatism. If something doesn't work, it doesn't matter how secure it is.

If something isn't secure, it doesn't work. At that point, you would've been better off shipping a wireframe.

A door with a broken lock still provides value. An online PDF converter on a website without SSL still provides value. I'm not saying security doesn't matter or that it shouldn't be a priority, but things don't need to be perfect to be useful. It makes sense to focus more on functionality than security in many areas. I host a bunch of web apps behind a firewall that aren't secure enough to expose to the public Internet. Even commercial ones.

Unfortunately, that's exactly the problem. If it didn't provide value, no one would use it and its lack of security would be a moot point.

The PDF converter is a great example. It's functional, people use it - to transfer potentially highly sensitive documents over an insecure connection. At that point, it provides value in the same way that a Nigerian prince provides banking services.

For you, no risk seems acceptable when it comes to security. That is generally not the case for most people, who will accept some level of risk (ie an insecure program) if it provides value to them. That's the whole point of risk management.

Pardon me for being pithy. We've all heard the adage about perfect security being a logical impossibility. I will say instead that if a tool doesn't have security proportionate to its risk factor integrated in its design, it doesn't work.

There are lots of decision points. Some people are deciding what to sell; others are deciding what to purchase. An organization that de-prioritizes security in what they produce could be punished by organizations that prioritize security in what they consume. In this way, decisions are shared to some extent. Consumers might be misled over the short-term, but at some point they become complicit.

If a datacenter continues to purchase a model of generator after five high-profile failures of that model, they can argue all they want that it is the only model on the market that meets their needs. But clearly uptime is not their biggest consideration.

> When you ship a software product, enable SELinux or AppArmor and audit what it does: then ship an SELinux/AppArmor profiles.

It's not just sysamins -- developers don't understand SELinux, either.

As a dev, I find least-privilege sandboxing (e.g., look at how sshd is structured) and capabilities (e.g. FreeBSD capsicum) somewhat non-intuitive, but at least tractable to understand. SELinux is a blackhole.

>> The whole container movement can be seen as putting the apps in a sarcophagus like Chernobyl. […] Who is responsible that it is air tight? Well, uh, nobody, really.

> The people who designed the container/sarcophagus system.

Original comment misses two nuances with the gripe.

1. Container creators and software creators are not the same people. So they can (and should!) have different goals and priorities. For containers, security and reliability. For software, make it work.

2. There is a nuanced, different interface between software-system and container-system, created by encapsulating a system-like environment inside the container. Much of what software does can be encapsulated. Which allows a more controlled (and much smaller) subset to exit the container.

> 1. Container creators and software creators are not the same people. So they can (and should!) have different goals and priorities. For containers, security and reliability. For software, make it work.

If the container system designers did their job properly it won't matter what the software does inside of it, as breakouts shouldn't be possible.

It has been a few years since I looked, but last time I checked there hasn't been a vulnerability in FreeBSD's jails code that allowed someone to break out. The closest to it was an issue with devfs that allowed 'tunnelling' out, but not with the actual Jails code itself:

* https://www.freebsd.org/security/advisories/FreeBSD-SA-14:07...

Meanwhile, with Docker (including CVE-2019-5736, which allows for overwriting runc on the host system):

* https://www.cvedetails.com/vulnerability-list/vendor_id-1353...

> 2. There is a nuanced, different interface between software-system and container-system

One keeps things inside and other other often doesn't?

One side has a huge footprint to secure (software-system), because it's every way software could ever need to interact with a local system.

The other can expose a much smaller one (container-system), because it only needs to include things one would have gone off-local-machine for (i.e. networking).

So from a security boundary, containers are basically a machine-internal firewall between programs and the host.

> So from a security boundary, containers are basically a machine-internal firewall between programs and the host.

Which is only useful if they actually provide security.

You're missing my point.

It's effectively impossible to ever provide security at the program-system interface, due to the surface area. (I.e. the SELinux problem)

The very concept of having a container (that internally simulates a system) creates fundamentally different opportunities that allow both (programs that work) and (security).

Whinging about whether or not current containers do a good or bad job of it is a less interesting, short term quibble.