5 ms·

Crap like this is why I dont run docker. I'm glad RedHat took a principled stance on it and dropped it. Podman doesn't punch holes you didn't ask for in your f

Crap like this is why I dont run docker. I'm glad RedHat took a principled stance on it and dropped it. Podman doesn't punch holes you didn't ask for in your firewall. What a ludicrous anti-feature.

thatwasunusual 5y ago
That might be true, but regardless of docker (or other, similar solutions), shouldn't MongoDB have had auth protection?
- haram_masala 5y ago
  Totally agreed with this. MongoDB’s default security posture is ridiculous, and amazingly it used to be even worse.
  - jbverschoor 5y ago
    It’s exactly the same for redis, which means if used for jobs, you can insert arbitrary code.
    - berkes 5y ago
      All my async job code lives in a codebase and redis merely contains the payload and some ids. What system, framework or stack are you using that stores the code of the job in the database? I'm curious, because I can imagine it solves some issues, e.g. deploying new code while allowing old code to finish running and scheduled jobs.
      - arp242 5y ago
        I think what they mean is Redis' Lua scripting stuff with EVAL and such. Also, if you have stuff like this in Redis, which will get picked up by a job runner: {"runjob": "foojob", "params": ["one", "two"]} Depending on how your job runner interprets this, it can be a big problem if people can write to this. At the very least it'll be a DoS in most cases, at worst (SQL) database, shell access, or leaking of passwords.
      - jbverschoor 5y ago
        Depending on the implementation of your job framework you can either: - run jobs that aren’t supposed to run (removing an account for example, is that’s scheduled after a 2 week grace period) maybe an export or import job. Can be anything of course - if your job runner allows scripts, or arbitrary class methods, you can do whatever you want - you can remove jobs if you feel like it - if you can escape redis because of whatever exploit, you now have access to the internal network In general I use sidekiq, but resque and inspired implementations generally work on simply calling perform(), so any class with such a method can be called, depending on the typesystem. The biggest two issues are the ability to perform any defined task, and the larger attack surface of an exposed redis server
- jbverschoor 5y ago
  From 3.6 the default binding is localhost. That would be ook, except that if you mail the power, you listen to all interfaces. This will happen with Redis as well and is a problem with both docker and its dockerfile
  - jessikat 5y ago
    Even on localhost, you should still use auth. One shouldn't naively assume someone can't break into your server.
    - habibur 5y ago
      If someone breaks into your server, database Auth won't protect you. And you have to reinstall everything including your database just to be sure he didn't leave holes in those. And the hacker can still delete your database or steal your data. He will simply download the datafiles and then delete those data from the server. Drop database done without a database password. And no, databases aren't kept encrypted on the server.
      - dnet 5y ago
        Not necessarily -- there can be a number of reasons one can access localhost over the loopback interface that does _not_ imply root access: SSRF, misconfigured tunnels, or just a plain unpriviliged account where the attacker couldn't perform privilege escalation (either because the attacker's incompetence or the system being up-to-date and/or hardened)
        habibur 5y ago
        Ok. Then add your password on these system when you design like that. That's not the default as most people feel otherwise.
    - jbverschoor 5y ago
      Yes. But by default things should not be open to anything but your machine. So let’s start blaming every piece of software that listens to localhost, but is exposed by docker. Not a fan of mongo, but the defaults are way better than before. Docker needs to fix their defaults
- Alupis 5y ago
  MySQL/MariaDB have a completely open root account too... although default firewall rules should prevent public access too, unless Docker likes to punch that hole open too. Yes, root account password and access permissions should be changed upon a fresh install, but the real issue here is Docker's "helpfulness" by opening ports without explicit permission. That's absurd, and has no reasonable excuse.
  - viraptor 5y ago
    https://dev.mysql.com/doc/refman/8.0/en/default-privileges.html https://dev.mysql.com/doc/refman/8.0/en/default-privileges.h... > Installation of MySQL creates only a 'root'@'localhost' superuser account that has all privileges and can do anything. It's only a local account. Sure, it would be great to have a password on it, but it's not "a completely open root account".
    - johannes1234321 5y ago
      > Sure, it would be great to have a password on it It has a password, which the user has to change, before they can do anything else. From that same page you linked: """ For data directory initialization performed manually using mysqld --initialize, mysqld generates an initial random password, marks it expired, and writes it to the server error log. """
    - slim 5y ago
      That documentation is outdated. Debian does not prompt you for a password, it creates a root account but you can't connect to the database using "mysql -uroot" you can only use it if you are root on the server (I forgot how they do the trick)
  - berkes 5y ago
    I've ran a few webhosting companies back in the heyday of LAMP/LEMP. This is a feature and a dangerous one. Our provisioning had to carefully manage the firewall during installation, because MySQL would be open to the world *while provisioning*. Often this is mere seconds or less, but on a reasonable popular webhosting, this is enough time for automated tools to take over the server. If, during that provisioning some other tool would start punching holes in the firewall you carefully manage from provisining, I would be enraged. I dislike Docker for a lot of reasons[0], and this kind of behaviour is one of them. So, yes: what MySQL or MongoDB do is dangerous and poor security practice. But what Docker does is worse: it breaks the countermeasures you take and rely on. IF all your layers of protection are removed by poor security practices of a tool that says "yea, but you need more than just this one layer" you still have no protection. [0] yet I do use it a lot on development-machines to run the services needed on localhost and not have to manage all those with apt/snap/brew or whatever they come with.
- MaxBarraclough 5y ago
  I had the 'opposite' thought: if the whole system were in a VPC, Docker wouldn't have had the authority to expose a port to the outside world. Looks like the author is ahead of both us. Later in the post he mentions both a planned transition to a VPC, and plans to beef up the security of MongoDB itself.
Proven 5y ago
Nonsense. If you know what you are doing, the feature automates things you know you want to do. As several other comments point out, to setup your DB server so that one open port can expose it to free access from the Internet is incompetent on multiple levels.

Crap like this is why I dont run docker. I'm glad RedHat took a principled stance on it and dropped it. Podman doesn't punch holes you didn't ask for in your firewall. What a ludicrous anti-feature.

thatwasunusual 5y ago

That might be true, but regardless of docker (or other, similar solutions), shouldn't MongoDB have had auth protection?

haram_masala 5y ago
Totally agreed with this. MongoDB’s default security posture is ridiculous, and amazingly it used to be even worse.
- jbverschoor 5y ago
  It’s exactly the same for redis, which means if used for jobs, you can insert arbitrary code.
  - berkes 5y ago
    All my async job code lives in a codebase and redis merely contains the payload and some ids. What system, framework or stack are you using that stores the code of the job in the database? I'm curious, because I can imagine it solves some issues, e.g. deploying new code while allowing old code to finish running and scheduled jobs.
    - arp242 5y ago
      I think what they mean is Redis' Lua scripting stuff with EVAL and such. Also, if you have stuff like this in Redis, which will get picked up by a job runner: {"runjob": "foojob", "params": ["one", "two"]} Depending on how your job runner interprets this, it can be a big problem if people can write to this. At the very least it'll be a DoS in most cases, at worst (SQL) database, shell access, or leaking of passwords.
    - jbverschoor 5y ago
      Depending on the implementation of your job framework you can either: - run jobs that aren’t supposed to run (removing an account for example, is that’s scheduled after a 2 week grace period) maybe an export or import job. Can be anything of course - if your job runner allows scripts, or arbitrary class methods, you can do whatever you want - you can remove jobs if you feel like it - if you can escape redis because of whatever exploit, you now have access to the internal network In general I use sidekiq, but resque and inspired implementations generally work on simply calling perform(), so any class with such a method can be called, depending on the typesystem. The biggest two issues are the ability to perform any defined task, and the larger attack surface of an exposed redis server
jbverschoor 5y ago
From 3.6 the default binding is localhost. That would be ook, except that if you mail the power, you listen to all interfaces. This will happen with Redis as well and is a problem with both docker and its dockerfile
- jessikat 5y ago
  Even on localhost, you should still use auth. One shouldn't naively assume someone can't break into your server.
  - habibur 5y ago
    If someone breaks into your server, database Auth won't protect you. And you have to reinstall everything including your database just to be sure he didn't leave holes in those. And the hacker can still delete your database or steal your data. He will simply download the datafiles and then delete those data from the server. Drop database done without a database password. And no, databases aren't kept encrypted on the server.
    - dnet 5y ago
      Not necessarily -- there can be a number of reasons one can access localhost over the loopback interface that does _not_ imply root access: SSRF, misconfigured tunnels, or just a plain unpriviliged account where the attacker couldn't perform privilege escalation (either because the attacker's incompetence or the system being up-to-date and/or hardened)
      - habibur 5y ago
        Ok. Then add your password on these system when you design like that. That's not the default as most people feel otherwise.
  - jbverschoor 5y ago
    Yes. But by default things should not be open to anything but your machine. So let’s start blaming every piece of software that listens to localhost, but is exposed by docker. Not a fan of mongo, but the defaults are way better than before. Docker needs to fix their defaults
Alupis 5y ago
MySQL/MariaDB have a completely open root account too... although default firewall rules should prevent public access too, unless Docker likes to punch that hole open too. Yes, root account password and access permissions should be changed upon a fresh install, but the real issue here is Docker's "helpfulness" by opening ports without explicit permission. That's absurd, and has no reasonable excuse.
- viraptor 5y ago
  https://dev.mysql.com/doc/refman/8.0/en/default-privileges.html https://dev.mysql.com/doc/refman/8.0/en/default-privileges.h... > Installation of MySQL creates only a 'root'@'localhost' superuser account that has all privileges and can do anything. It's only a local account. Sure, it would be great to have a password on it, but it's not "a completely open root account".
  - johannes1234321 5y ago
    > Sure, it would be great to have a password on it It has a password, which the user has to change, before they can do anything else. From that same page you linked: """ For data directory initialization performed manually using mysqld --initialize, mysqld generates an initial random password, marks it expired, and writes it to the server error log. """
  - slim 5y ago
    That documentation is outdated. Debian does not prompt you for a password, it creates a root account but you can't connect to the database using "mysql -uroot" you can only use it if you are root on the server (I forgot how they do the trick)
- berkes 5y ago
  I've ran a few webhosting companies back in the heyday of LAMP/LEMP. This is a feature and a dangerous one. Our provisioning had to carefully manage the firewall during installation, because MySQL would be open to the world *while provisioning*. Often this is mere seconds or less, but on a reasonable popular webhosting, this is enough time for automated tools to take over the server. If, during that provisioning some other tool would start punching holes in the firewall you carefully manage from provisining, I would be enraged. I dislike Docker for a lot of reasons[0], and this kind of behaviour is one of them. So, yes: what MySQL or MongoDB do is dangerous and poor security practice. But what Docker does is worse: it breaks the countermeasures you take and rely on. IF all your layers of protection are removed by poor security practices of a tool that says "yea, but you need more than just this one layer" you still have no protection. [0] yet I do use it a lot on development-machines to run the services needed on localhost and not have to manage all those with apt/snap/brew or whatever they come with.
MaxBarraclough 5y ago
I had the 'opposite' thought: if the whole system were in a VPC, Docker wouldn't have had the authority to expose a port to the outside world. Looks like the author is ahead of both us. Later in the post he mentions both a planned transition to a VPC, and plans to beef up the security of MongoDB itself.

Proven 5y ago

Nonsense. If you know what you are doing, the feature automates things you know you want to do. As several other comments point out, to setup your DB server so that one open port can expose it to free access from the Internet is incompetent on multiple levels.