9 ms·

Containers, aka "just download random crap off the internet and run it as root, #YOLO" are an anti-security device.

by otabdeveloper4 5y ago

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.
      - throwaway894345 5y ago
        You could make the same analogy with github or npm or whatever unvetted repository. Nothing specific to containers here.
        yjftsjthsd-h 5y ago
        To varying degrees yes you can, and should, and those are absolutely worth caution - we do have semi-regular issues with malicious stuff getting uploaded to NPM; that github somehow has escaped major (publicized) problems is the real surprise.
        throwaway894345 5y ago
        I agree, and to be clear, that's precisely my point--your claim that "Docker Hub makes it easy to download unvetted [executables]" is a property it shares with all unvetted executable repositories--nothing to do with containers in particular. :)
      - nuerow 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. Containers might have provided a convenient way to package, distribute, and deploy software, but that's just a nice-to-have complementing the whole reason anyone adopts containers. To put things in perspective, while Docker is practically a household name, does snap ring a bell to anyone? Does anyone bother at all with snap? > 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. This assertion is proven false with the inception of container registry services provided by service providers such as GitLab, GitHub, and all major cloud service providers such as AWS, Google Cloud, and Azure, and even lesser services such as Alibaba cloud and IBM cloud. These services might make container images available to the public, but their main role is to allow people like you and me to push their own container images to be pulled by your container orchestration services. In fact, even if you adopt third-party services you end up either using the official images made available by each project or repackaging the software yourself to reflect your own config and deployment needs.
  - throwaway894345 5y ago
    I don't know how to take this comment seriously. Of course people don't want to deploy "random crap", but yes, people want to deploy software more easily--it's not clear to me why this is such an awful thing. > I'd wager "rootless" is a bug, not a feature in this scenario. You would be mistaken. Containers don't have any magic that makes it easier or harder to run as root. In this respect, they're just Linux processes, and an administrator can run them as root or not. And like Linux processes, the widely-understood best practice is to run them without root, and indeed many orchestrators require you to explicitly opt-in to "privileged execution". As point of fact, containers have strictly more security layers than vanilla Linux processes. They are typically thought to have weaker isolation properties than VMs, which is why we (as an industry) invariably run containers (and vanilla Linux processes) inside of VMs or forego multi-tenancy altogether.
    - otabdeveloper4 5y ago
      You misunderstand how it is in the wild. Much (most?) of the time Docker and docker-compose are used to package big-ball-of-legacy-mud applications and their dependencies and push them out on the unsuspecting world. Installation instructions for most web app software today is "here, download and run this docker-compose.yml". Of course nobody vets or even looks at the mess inside the compose file, and most of this software won't even run without root privileges. (Because it hooks into various system bits and violates all sorts of isolation rules.) People value Docker as a packaging tool; especially as a go-to tool for packaging legacy crap and software-as-a-pet systems. Running this stuff without any sort of checking and as root is bonkers, but it is what it is. We're kind of back in the Windows 95 era of packaging software as far as server backends go. Maybe it will change after some very serious worms and viruses his the Docker ecosystem. (Windows changed very slowly and only after tremendous pressure from cybercrime.)
      - johnchristopher 5y ago
        > Of course nobody vets or even looks at the mess inside the compose file, and most of this software won't even run without root privileges. (Because it hooks into various system bits and violates all sorts of isolation rules.) I don't know about that. I recently was tasked with installing a web service, running in a container. First thing I noticed was that the container was bundling a nginx reverse proxy, a node js server, a redis database, a rabbit-mq service and a pgsql database. I noticed because after installing the whole thing I wondered why the database was working fine even when the env variables for the pgsql were wrong. Those env variables are in the README (along with other variables holding secrets so it's not clear what is necessary and what is not from reading the documentation). Then trying to proxying the thing I, after an afternoon of banging my head, I remembered docker has an impact on iptables rules. The documentation and support forums mixes both nginx as the reverse proxy/frontend running inside the container and nginx running in front of it. So, documentation was not good and I don't see how anyone downloading this docker-compose.yml file would be able to run it without digging through it but it doesn't mean a well documented shipped docker bundle with 1 process per container is hard or impossible or not desirable. I do agree that the tendency of some projects to ship a docker-compose.yml with one service running multiple processes (databases, server, proxy, cache, etc.) is a giant PITA. I mostly see that from opensource projects with a paid enterprise version. I am pretty sure it's never the bundle they are actually running in production. Now, when I read some `sudo docker` I think the same things that I think when I read `sudo pip install`.
- ghostly_s 5y ago
  How do you handle access to network shares?
  - mavhc 5y ago
    I've not yet, but root inside the container is the user docker is running as outside, so I assume if that user can access the share it would be ok. What protocol were you thinking of?
    - ghostly_s 5y ago
      NFS or SMB. Just wondering as I've recently started exploring (lxc) containerization in my home lab and that was the big roadblock I hit with unprivileged containers. I guess the solution as you suggest is to mount in host and bind-mount in the ct, but that seems pretty unappealing for multiple reasons- it breaks the logical compartmentalization of app config in the container, no visibility on the server of which ct owns a connection, can't scope nfs permissions per container etc.
rubyist5eva 5y ago
https://developers.redhat.com/blog/2020/09/25/rootless-containers-with-podman-the-basics https://developers.redhat.com/blog/2020/09/25/rootless-conta... https://docs.docker.com/engine/security/rootless/ https://docs.docker.com/engine/security/rootless/
throwaway894345 5y ago
This obviously has nothing to do with containers. You can download and run untrusted code (as root or otherwise) whether or not it’s containerized, and indeed containers at least give you some degree of isolation. What would possess someone to post such embarrassingly obvious misinformation?
- jrochkind1 5y ago
  What determines if code is "untrusted" or not anyway? It's fine to run postgres or redis (someone else's code! that I have certainly not audited!) on a server, but as soon as you run it in a container that's... less secure?
  - throwaway894345 5y ago
    That is certainly the perception. Like any software, you have to make sure you're pulling from a reliable source--if you're pulling an image from `hub.docker.com/r/definitely-not-a-hacker/postgres` rather than the official postgres image, you're exposing yourself. But it's transparently ignorant to argue that this is particular to containers--one can also download a postgres ELF binary from an untrusted source. I really think a lot of criticism of containers is absurdly low quality (e.g., criticizing containers for issues that are universal to all software)--it feels like people are really grasping at straws. One gets the distinct impression that some people have spent years or even decades perfecting bespoke, rube-goldberg-esque application runtime environments and now containers are obsoleting their value proposition. Of course, I'm very hesitant to psychoanalyze and would never argue that any individual is so motivated, but this is the impression I get in aggregate.
  - xorcist 5y ago
    Surely it's a bit more complex question than that. The traditional way of running software includes some sort of privilege management, uids, ulimits, chroots but sometimes also things like pledge and selinux. Those things are sometimes summarizes as privilege minimization. Privilege minization is much harder when stuffing everything in a container. I'd wager that running Chrome normally is probably safer than running it inside Docker, for example, because not all sandboxing functionality works when running inside a container. So it would depend on what software, and what type of container.

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.
    - throwaway894345 5y ago
      You could make the same analogy with github or npm or whatever unvetted repository. Nothing specific to containers here.
      - yjftsjthsd-h 5y ago
        To varying degrees yes you can, and should, and those are absolutely worth caution - we do have semi-regular issues with malicious stuff getting uploaded to NPM; that github somehow has escaped major (publicized) problems is the real surprise.
        throwaway894345 5y ago
        I agree, and to be clear, that's precisely my point--your claim that "Docker Hub makes it easy to download unvetted [executables]" is a property it shares with all unvetted executable repositories--nothing to do with containers in particular. :)
    - nuerow 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. Containers might have provided a convenient way to package, distribute, and deploy software, but that's just a nice-to-have complementing the whole reason anyone adopts containers. To put things in perspective, while Docker is practically a household name, does snap ring a bell to anyone? Does anyone bother at all with snap? > 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. This assertion is proven false with the inception of container registry services provided by service providers such as GitLab, GitHub, and all major cloud service providers such as AWS, Google Cloud, and Azure, and even lesser services such as Alibaba cloud and IBM cloud. These services might make container images available to the public, but their main role is to allow people like you and me to push their own container images to be pulled by your container orchestration services. In fact, even if you adopt third-party services you end up either using the official images made available by each project or repackaging the software yourself to reflect your own config and deployment needs.
- throwaway894345 5y ago
  I don't know how to take this comment seriously. Of course people don't want to deploy "random crap", but yes, people want to deploy software more easily--it's not clear to me why this is such an awful thing. > I'd wager "rootless" is a bug, not a feature in this scenario. You would be mistaken. Containers don't have any magic that makes it easier or harder to run as root. In this respect, they're just Linux processes, and an administrator can run them as root or not. And like Linux processes, the widely-understood best practice is to run them without root, and indeed many orchestrators require you to explicitly opt-in to "privileged execution". As point of fact, containers have strictly more security layers than vanilla Linux processes. They are typically thought to have weaker isolation properties than VMs, which is why we (as an industry) invariably run containers (and vanilla Linux processes) inside of VMs or forego multi-tenancy altogether.
  - otabdeveloper4 5y ago
    You misunderstand how it is in the wild. Much (most?) of the time Docker and docker-compose are used to package big-ball-of-legacy-mud applications and their dependencies and push them out on the unsuspecting world. Installation instructions for most web app software today is "here, download and run this docker-compose.yml". Of course nobody vets or even looks at the mess inside the compose file, and most of this software won't even run without root privileges. (Because it hooks into various system bits and violates all sorts of isolation rules.) People value Docker as a packaging tool; especially as a go-to tool for packaging legacy crap and software-as-a-pet systems. Running this stuff without any sort of checking and as root is bonkers, but it is what it is. We're kind of back in the Windows 95 era of packaging software as far as server backends go. Maybe it will change after some very serious worms and viruses his the Docker ecosystem. (Windows changed very slowly and only after tremendous pressure from cybercrime.)
    - johnchristopher 5y ago
      > Of course nobody vets or even looks at the mess inside the compose file, and most of this software won't even run without root privileges. (Because it hooks into various system bits and violates all sorts of isolation rules.) I don't know about that. I recently was tasked with installing a web service, running in a container. First thing I noticed was that the container was bundling a nginx reverse proxy, a node js server, a redis database, a rabbit-mq service and a pgsql database. I noticed because after installing the whole thing I wondered why the database was working fine even when the env variables for the pgsql were wrong. Those env variables are in the README (along with other variables holding secrets so it's not clear what is necessary and what is not from reading the documentation). Then trying to proxying the thing I, after an afternoon of banging my head, I remembered docker has an impact on iptables rules. The documentation and support forums mixes both nginx as the reverse proxy/frontend running inside the container and nginx running in front of it. So, documentation was not good and I don't see how anyone downloading this docker-compose.yml file would be able to run it without digging through it but it doesn't mean a well documented shipped docker bundle with 1 process per container is hard or impossible or not desirable. I do agree that the tendency of some projects to ship a docker-compose.yml with one service running multiple processes (databases, server, proxy, cache, etc.) is a giant PITA. I mostly see that from opensource projects with a paid enterprise version. I am pretty sure it's never the bundle they are actually running in production. Now, when I read some `sudo docker` I think the same things that I think when I read `sudo pip install`.
ghostly_s 5y ago
How do you handle access to network shares?
- mavhc 5y ago
  I've not yet, but root inside the container is the user docker is running as outside, so I assume if that user can access the share it would be ok. What protocol were you thinking of?
  - ghostly_s 5y ago
    NFS or SMB. Just wondering as I've recently started exploring (lxc) containerization in my home lab and that was the big roadblock I hit with unprivileged containers. I guess the solution as you suggest is to mount in host and bind-mount in the ct, but that seems pretty unappealing for multiple reasons- it breaks the logical compartmentalization of app config in the container, no visibility on the server of which ct owns a connection, can't scope nfs permissions per container etc.

rubyist5eva 5y ago

https://developers.redhat.com/blog/2020/09/25/rootless-containers-with-podman-the-basics https://developers.redhat.com/blog/2020/09/25/rootless-conta... https://docs.docker.com/engine/security/rootless/ https://docs.docker.com/engine/security/rootless/

throwaway894345 5y ago

This obviously has nothing to do with containers. You can download and run untrusted code (as root or otherwise) whether or not it’s containerized, and indeed containers at least give you some degree of isolation. What would possess someone to post such embarrassingly obvious misinformation?

jrochkind1 5y ago
What determines if code is "untrusted" or not anyway? It's fine to run postgres or redis (someone else's code! that I have certainly not audited!) on a server, but as soon as you run it in a container that's... less secure?
- throwaway894345 5y ago
  That is certainly the perception. Like any software, you have to make sure you're pulling from a reliable source--if you're pulling an image from `hub.docker.com/r/definitely-not-a-hacker/postgres` rather than the official postgres image, you're exposing yourself. But it's transparently ignorant to argue that this is particular to containers--one can also download a postgres ELF binary from an untrusted source. I really think a lot of criticism of containers is absurdly low quality (e.g., criticizing containers for issues that are universal to all software)--it feels like people are really grasping at straws. One gets the distinct impression that some people have spent years or even decades perfecting bespoke, rube-goldberg-esque application runtime environments and now containers are obsoleting their value proposition. Of course, I'm very hesitant to psychoanalyze and would never argue that any individual is so motivated, but this is the impression I get in aggregate.
- xorcist 5y ago
  Surely it's a bit more complex question than that. The traditional way of running software includes some sort of privilege management, uids, ulimits, chroots but sometimes also things like pledge and selinux. Those things are sometimes summarizes as privilege minimization. Privilege minization is much harder when stuffing everything in a container. I'd wager that running Chrome normally is probably safer than running it inside Docker, for example, because not all sandboxing functionality works when running inside a container. So it would depend on what software, and what type of container.