DEV Community

Discussion on: Be careful with Docker ports!

Collapse
exadra37 profile image
Paulo Renato

First of all thanks for replying to me, I love to exchange ideas, but sometimes I can be very passionated about them.

My affirmation was more in thinking on vendors that do software, like databases and other tooling, not specifically Operating Systems.

But addressing your points:

Also, declaring that vendors "do insecure software by default, just for the sake of developer convenience" I think it is a bit narrow view.

Not that narrow, because security is always seen as friction for user satisfaction, thus is more often that not relaxed or non existent for user satisfaction, time to market, money costs, etc.

I've been working, on and off, with Linux since the 90's and the default security model hasn't changed at all since.

I see this as a problem, because the threat model changed a lot, and the security flaws keep appearing in software that was judged to be secure for decades.

Yet, the Linux ecosystem is still considered one of the most secure ones. Given this statement above,

I agree and that is why I use it in my Desktop, but that doesn't mean that it could not be much better.

Linux firewalls come with default rule to ALLOW ALL traffic. Is this really for developer convenience? How would you be able to access a remote server if the default settings are DROP ALL traffic?

The ssh port registered in IANA is the 22, thus it could be open by default for users with a password, and everything else closed. As it is now you have millions of servers deployed by developers that don't have firewall enabled at all or to far open, and this is due to not knowing or because they forgot, or are just lazy. Either way data breaches keep pilling up and our data exposed.

Or how about if the regular user you connect to in Linux would not have, by default, rights to even write in his own home folder?

If its is home folder off-course the system should create with permission for it to write and read, but not with permissions for the world to read it, as it is now.

I am just saying, there are as many different points of view as people involved, either developers or users, in a specific project.

Yes you are correct, but security is not a first class citizen in these projects, and more often than not its an after though. Once more the current state of data breaches due to the lack of security in lots of things we use daily is just alarming.

Stop for a second and validate first the assumption that you might have just mist something before declaring that a project is insecure by default for the sake of convenience.

I have stopped a lot of times to think on this in my entire career, and more time goes more I am convinced that by nature projects where not built with security as a first class citizen from day zero, but hopefully the huge fines and frequents data breaches are changing this behaviour.

See for example MysQL, ElasticSearch, MongoDB, where all them allow to be installed with insecure defaults, aka without authentication, and then you have them in production public accessible, because the developer forgot or was not knowing that was in need of securing them. You can use Shodan to see some public expose ones. Just change the search query to your software of choice.

Thread Thread
rendlerdenis profile image
Denis Rendler

First of all thanks for replying to me, I love to exchange ideas, but sometimes I can be very passionated about them.

Don't worry. I think we all do that, when it comes to security at least. :)

Myself, being a developer constantly fighting with the customer to keep their app safe I agree 99% with you. I agree on the fact that usually security isn't thought of during development and maybe not even after the product has been released. But there is also the fact that there are times when thinking about security too much can hinder a product being released.

The threat model is indeed a living organism which is always changing. That is why we need more people to be aware of security issues. And the new laws and fines will help on that, for a time at least.

But I am wondering how would one go about thinking of the threat models for their product when their product is used in so many different scenarios.
Let's take your database example. How would you go about building a threat model when your product is used for storage, for analytics or for powering the next unsought of product that will help millions of people. A db is used in servers, in mobile apps or even embedded devices. And I think we can continue indefinitely with this example alone.

How would you go about building a threat model that will cover all cases when the threat model is not the same for any two people?

Although myself and my wife share the same house, same car, same hopes and dreams our threat models are radically different. She enjoys and requires usability while myself I need security and awareness above all. For example, a simple backup server for our photos it took me several days to plan, build and configure before I even mentioned to her that I am doing it. And all she wanted was a place where to offload her phone photos but could be reachable when she wanted/needed them. Any cloud solution could have helped with that and made it faster.

Circling back to Docker, Docker doesn't do security, it does virtualization.
The security aspect that results from the application's isolated environment is just a bonus.

I see a lot of people selling Docker as an extra layer of security, which is just wrong. It doesn't offer anything else that any other virtualization environment doesn't offer.

They only do virtualization because that is where they are good at. That is why they offload the security part to other, more experienced, more mature systems like AppArmor, SELinux, Linux's user management and network handling.

That is why I said Docker is not bypassing the firewall, but instead it uses it to connect the virtualized environment where the app runs to the real world.

The docs are missing, or aren't putting this information more upfront? I agree! But let's be honest, who's docs don't need improvements.

And I would love to continue, but I need to come back to my project. Who knows, maybe someday we will meet face to face and continue this discussion. I would certainly love so.