4 ms·

Any of the capabilities needed by the exploits is in linux only available to root users. And are now granted to a container. So these ”escapes“ are basically g

• t8sr 3y ago
  In practice, though, containers are given these capabilities all the time, and in infosec people do refer to these as escapes. Generally, it’s not the stuff the container is intended to run that’s doing the escape, though. This is usually the second step, after getting local execution through a vulnerability in the application running in the container.
  • ptx 3y ago
    Why are these capabilities usually granted, in your experience?
    • achierius 3y ago
      In my experience profilers often need SYS_ADMIN or other capabilities. This is true even outside of a container. If I'm forced to work inside a container without the ability to add that cap, performance optimization work becomes very difficult.
    • blackmesaind 3y ago
      User error is the source of many vulnerabilities that shouldn't exist.
    • t8sr 3y ago
      I posted another comment with some examples, but I think the general answer, IME, is that it's usually easier to do the wrong thing than to do the right thing. Security boundaries in Cloud-style Linux are typically hard to configure and not well documented. Engineers have deadlines and they're interested in building things, not debugging permissions. They'll do whatever is the easiest to get the system working. This, by the way, is why I think Google had it right by splitting most products into SWE and SRE groups, so you had a group of people who could focus full-time on the production environment. SWEs are rewarded for building and deploying stuff, so they're going to build and deploy stuff.
• bryanrasmussen 3y ago
  Raymond Chen had a blog post complaining of bug reports that started with - assuming the attacker has root access... unfortunately cannot find it anymore. on edit - maybe it was write permissions to the file system, but largely the same level of "once you have this it is game over"
  • rmccue 3y ago
    “It rather involved being on the other side of this airtight hatchway” - there’s a couple posts in the series. https://devblogs.microsoft.com/oldnewthing/20060508-22/?p=31283 https://devblogs.microsoft.com/oldnewthing/20060508-22/?p=31...
• nunez 3y ago
  Which is relevant because containerd most commonly runs as root, even in Kubernetes.
  • bolobo 3y ago
    It doesn't matter, the "root" user inside the container is still jailed and none of these tricks will allow that user to escape.
  • mmis1000 3y ago
    Actually, no. The root in container isn't actually uid 0 in host system if you setup things correctly. Linux user namespace can offset uid in a container by certain number. Effectively make uid 0 actually uid 60000, uid 1000 as uid 61000 and so on. And in this case. If you escaped the container, you are literally nobody. All you allowed to read is public files that any user can read. By the way. If you use rootless container, this is the default settings you will get. Since you don't have access to uid0 at first place.
    • ThePowerOfFuet 3y ago
      >if you setup things correctly Judging by the number of HOWTOs I see on GitHub and YouTube that tell you to check the Privileged box, this assumption isn't worth what you think it is.
    • nunez 3y ago
      You're correct in that uid 0 in the container is faked through userns, but you can easily bypass that with a privileged container or adding the CAP_ADMIN capability. Yes, you can disable creating privileged containers within Kubernetes, but that isn't something you can rely on. If the runtime is running as root, which it often is, you can also become real root within the container under these conditions.
• _8j50 3y ago
  That's not true, those capabilities can be granted to normal users. If the container is badly composed enough, sys admins might grant a user those caps so they can avoid security alerts about running containers as root.