15 ms·

It's important to understand that containers are not a security device. Containers are a mechanism to separate resources used by processes. You should not assum

• freedomben 5y ago
  > You should not assume any significant security benefits to containers, regardless of what anyone claims (even a kernel developer - maybe especially them....) because it all depends on Linux kernel security, which is pretty crap. Completely disagree. How much experience/exposure do you have to kernel security that you say is crap? > It uses Micro VMs rather than just kernel-level restrictions, so even a Linux kernel security bug shouldn't be able to jump out to the host or other containers/Firecrackers. You realize that firecracker uses KVM, which is part of the "crap" kernel that you don't trust? A "Linux kernel security bug" could absolutely allow a Firecracker VM to jump to the host or other containers/Firecrackers.
  • kitd 5y ago
    The attack surface of a micro VM is tiny compared with that of a full Linux kernel. That's the issue.
    • freedomben 5y ago
      I don't disagree with you, but that's a very different thing than what GP said. Comparing attack surface is a very different thing than saying that containers don't give you any practical security over a non-containerized process (my paraphrase of OP, subject to misinterpretation). The former (comparing attack surface) is a useful exercise in a high-security environment. The latter is simply a ridiculous thing to say.
      • throwaway20371 5y ago
        Trying to secure a container via non-VM means is a painful slog. You can pretend containers give you security, and then one of the hundreds of different attack vectors provides a breakout. It's been demonstrated time and again, largely because Linux security is just shit and always has been.
        • freedomben 5y ago
          I did it this morning and it wasn't a painful slog, because I don't have to start from scratch with just docker every time. I can reuse work done by others, and there are numerous tools that assist (OpenShift, selinux, seccomp for example). Your example of firecracker is the same thing. It is a tool wrapped around a lower-level implementation (KVM) that covers the primitives so they are easier/faster to use. If your complaint is that container implementations leave the hardening scope to other tools, then sure, but I would argue that's just philosophy difference between the unix approach of do one thing and do it well, and chain tools together to solve problems, and the approach of one program to rule them all.
          • throwaway20371 5y ago
            It's not a philosophical difference, it's just complexity. More complex systems are more prone to failure. If the security system is more complex to set up, it's more likely to fail. More code means more bugs, and more domain-specific knowledge leads to more potential for user error. So if you have 'one program to secure it all', it's almost guaranteed to be better than having to use many programs all in the right way. And it isn't even a defense-in-depth issue because all those layers added to container security are really just to avoid the much larger attack surface; getting rid of attack surfaces reduces what you need to defend.
  • throwaway20371 5y ago
    I don't think there's ever been a year without a half dozen privesc holes in the Linux kernel. Linus is also belligerently anti-security because he thinks it always results in worse user outcomes. And containers were never created with security as a top priority, they're just an amalgamation of resource abstractions, so of course it works as well as anything else not designed with security in mind. The hypervisor isolates guest kernel bugs from the host by nature of strictly controlling resource use from the lowest level. There are of course hypervisor bugs that allow breakouts, but they are a couple orders of magnitude rarer than the typical Linux privesc bug.
• otabdeveloper4 5y ago
  Containers, aka "just download random crap off the internet and run it as root, #YOLO" are an anti-security device.
  • mavhc 5y ago
    All my containers are rootless
    • otabdeveloper4 5y ago
      > not my container! Good for you, seriously. But that's not why people use containers. People use containers because they want to deploy random crap from the internet at the press of a button. I'd wager "rootless" is a bug, not a feature in this scenario.
      • nuerow 5y ago
        > But that's not why people use containers. People use containers because they want to deploy random crap from the internet at the press of a button. No, it really isn't. At all. In fact, your comment is so out of touch it actually reads like a poor attempt at trolling. People use containers because they offer an easy and very convenient and self-contained platform to build, deploy, configure, and run multiple instances of the same application, regardless of node or platform. In fact, if you ever manage to get any experience with containerized applications you'll eventually notice that in all containerized apps the bulk of applications, specially microservice-based applications, are comprised of apps developed in-house. On top of that, there is a wealth of container orchestration systems that provide support for blue-green deployments, autoscaling, system introspection, auditing, and even secrets management, not to mention networking. Your assertion makes as much sense as claiming that people use Linux distros a because they want to deploy random crap from the internet at the press of a button, just because they provide a package management system.
        • yjftsjthsd-h 5y ago
          You're going a bit far the other way, I think. People definitely use containers because they're a nice workflow, and yes a lot of containers are shipping all in-house code. But to ignore the popularity of Docker Hub and claim that people aren't also jumping head first into containers because they make it easy to grab random unvetted binaries is a step to far. > Your assertion makes as much sense as claiming that people use Linux distros a because they want to deploy random crap from the internet at the press of a button, just because they provide a package management system. If a major reason were using Linux was for the AUR, then that'd be a valid criticism. In practice, most distros ship a package manager that only pulls from official repos, and changing that requires jumping through hoops (even Arch with the AUR requires manual work to build an AUR package). And in practice, a lot of people are pulling random unofficial images off Docker Hub (and gcr.io and such) and just running them without review.
• cpuguy83 5y ago
  It is important to understand that as implemented by runtimes such as docker, containerd, cri-o, and podman, containers are absolutely a security device. These things force the application to run in restricted environments where capabilities are reduced, system calls are filtered, apparmor profiles and selinux labels are applied, among other things. These are the same sort of things that chrome, for instance, does to make it harder to do bad things from the browser. They are hardening techniques. Images are automatically checksummed on download, and for certain things even signatures are checked (more of this soon). Just because they do not protect you from a kernel exploit (also actually not true, seccomp filters have prevented a number of kernel exploits from inside the container) does not mean they are not added security. The important thing to know what your attack surface is and what is acceptable risk for the workloads you are running. And yes, it is important to understand that containers do not isolate you completely from kernel exploits. It is also important to understand the control plane (runtime up to the orchestrator) is much more likely to introduce security issues than the container itself.
  • AtNightWeCode 5y ago
    Agree, if you then like some of the huge companies spin up containers per user/customer it works more or less as sandboxes giving huge security benefits.
  • raesene9 5y ago
    Obviously containers do add a of security relative to uncontained processes but there are security challenges(as I'm sure you're aware) There are multiple independent projects involved in securing a standard orchestrated docker style container (some of the set of Linux kernel/Linux distro/runc/containerd/docker/k8s) and no obvious owner of overall security configuration and problems. we've seen examples of this, e.g. k8s disabling Docker's seccomp filter, or more recently the difficulty in how to handle clone(3) and seccomp filters. For me it's that comparison with dedicated security sandboxes, is that in other projects there's a single team handling the whole security picture , which is likely to make things easier to manage.
  • andrewstuart2 5y ago
    It's also important to remember that security is not merely confidentiality. Kubernetes and docker both assist in availability and integrity through redundancy and (at least for most of its history) the ability to run code by content-addressed cryptographic hashes. And validate other signatures etc. There are a ton of security mechanisms that are enabled by the ecosystem itself, even if it does introduce new complexities and does have certain weaknesses against full hardware virtualization. It also has significant and meaningful security strengths (namely in availability via lower resource usage) against exclusively using hardware virtualization.
• kodah 5y ago
  I recently wrote a white paper on host level container security for a security oriented product. Say what you want about kernel security, but most side channel attacks are statistically using syscalls which are highly unusual for a regular, hosted application to make. Using a combination of SecComp and LSM apps (SELinux/AppArmor) you can defend against most of these attacks. You are right that containers alone are not sandboxes, but namespacing does help in terms of isolation. If you want to sacrifice performance for some further security you can use an application kernel, which further defends the host kernel. Additionally, you can try to sandbox with host and node level isolation for services, which refines the application syscall profile to be very consistent and predictable. Then if something unusual occurs on the host (like writing to disk) then you can take definitive action like shutting the host down. That's some of the principles Bottle rocket was written on, among others.
  • Ballu 5y ago
    Link to white paper, will be appreciated.
    • kodah 5y ago
      It still has a ways to go before it's disseminated externally, but I'll reply here when it does.
• paxys 5y ago
  They are most definitely a security device. They are not the only security device.
• jiggawatts 5y ago
  I’ve seen customers assume that because they’ve heard that Linux containers are secure, they can use containers to secure Windows applications. Microsoft ignores security reports related to container escape vulnerabilities because they don’t consider it to be a security boundary!
• mindwok 5y ago
  Containers may not be a security boundary yet, but they do promise a level of security and even though the kernel and various runtimes may not be there yet, one day they will be. Every time there's a container escape or privilege escalation, it's treated as serious and patched. I look forward to the day when we can confidently say that containers are in fact a security boundary.