3 ms·

> 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, r

> 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. If it's not secure don't sell it as secure: see the difference between Linux containers and FreeBSD jails or Solaris zones. > You can't even blame the applications for that. Let's say you want to build a good, secure application. How do you know what files your application will try to open? What syscalls it wants to call? Library and framework functions tend to not document that properly. As a developer / software "engineer" it is your responsibility to know how the components you choose work and how much you can rely on them. When a structural engineer selects certain types of steel or concrete to be used in the construction of a bridge, it is their responsibility to know the characteristics of the raw materials. When you ship a software product, enable SELinux or AppArmor and audit what it does: then ship an SELinux/AppArmor profiles. See also OpenBSD's pledge(2) framework where the developer embeds system calls in their (C) code to promise to only access certain OS features: * https://awesomekling.github.io/pledge-and-unveil-in-SerenityOS/ https://awesomekling.github.io/pledge-and-unveil-in-Serenity... * https://man.openbsd.org/pledge.2 https://man.openbsd.org/pledge.2

consp 5y ago
> 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.
- brightball 5y ago
  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.
  - caymanjim 5y ago
    It's pragmatism. If something doesn't work, it doesn't matter how secure it is.
    - paledot 5y ago
      If something isn't secure, it doesn't work. At that point, you would've been better off shipping a wireframe.
      - caymanjim 5y ago
        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.
        paledot 5y ago
        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.
      - throwaway889900 5y ago
        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.
        paledot 5y ago
        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.
ethbr0 5y ago
>> 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.
- throw0101a 5y ago
  > 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.devfs.asc 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-13534/product_id-28125/Docker-Docker.html 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?
  - ethbr0 5y ago
    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.
loeg 5y ago
> 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.

consp 5y ago

> 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.

brightball 5y ago
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.
- caymanjim 5y ago
  It's pragmatism. If something doesn't work, it doesn't matter how secure it is.
  - paledot 5y ago
    If something isn't secure, it doesn't work. At that point, you would've been better off shipping a wireframe.
    - caymanjim 5y ago
      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.
      - paledot 5y ago
        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.
    - throwaway889900 5y ago
      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.
      - paledot 5y ago
        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.

ethbr0 5y ago

>> 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.

throw0101a 5y ago
> 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.devfs.asc 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-13534/product_id-28125/Docker-Docker.html 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?
- ethbr0 5y ago
  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.

loeg 5y ago

> 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.