[Feature Request] Docker Support

[rauchenwaldc (Christian Rauchenwald)]

That was fast.

@pmueller

no, this also applies on containers becoming compromised during their runtime.

But wouldn’t that limit the issue to the container?

@pmueller

However, the difference between Pakfire and Docker is that we, the IPFire team, still have an idea about what users are possibly running on their firewalls.

You could simply point out that you don’t offer support for services run through Docker and require users to disable Docker to receive support?
When users have issues the first advice would be to turn off docker and check if the issue still persists.

@pmueller

An attacker could prepare a (privileged) container with all his tools, which he only needs to download on an IPFire system.

But that would already require that the attacker already has access to the machine or not?

@pmueller

Loading custom kernel modules (mostly rootkits) is the archetype of an attack, but not the only possibility to to malicious things. Extracting memory addresses from the kernel could be used to make bypassing ASLR more easy, injecting bogus TTY descriptors might allow hijacking other processes - this goes on forever.

As you may have guessed that is something I lack expertise in. But just to be clear on one point you mentioned here, shouldn’t your sealed kernel make it impossible to load custom kernel modules?

@pmueller

The more freedom you give to users, the more ways do they get to configure their system in an unsafe way or break it completely.

We have a problem with some users lacking even most basic networking knowledge already. I certainly do not want them to be able to run containers on their IPFire machine.

IMHO that’s not really your problem but the user’s problem. It’s like not knowing how to drive but still deciding to drive like an idiot in a new Porsche. The dealership certainly won’t be blamed or liable for any damages caused by the dumb driver.

@pmueller

No offense intended, but if you have had the money to buy some hardware for serving as your firewall, an ARM board (* Pi or similar) should not exceed your budget either.

None taken. I do have a Pi and I also have the money to put another machine into my 19-inch rack at home, but running a STORJ node doesn’t justify additional expenses.
Having a machine already running 24/7 (ipfire) and some additional HDDs, however, makes it a “lucrative” idea to run STORJ on ipfire. (And STORJ requires Docker).
I mentioned the budgeting issue because I assume that there are quite a few ipfire users that run ipfire on some old machine and don’t have the funds or - like with STORJ - want to run some additional service that does not justify spending additional money.

@pmueller

No, it is not enough to provide that integration, since users will stumble across bugs or want additional features, causing additional “support load” here

See above, simply don’t offer support for services running in Docker containers (besides containers that you may eventually provide yourself)

@pmueller

…we are then dealing with IPFire machines actually abused to serve as a all-in-one PC for people who typically lack both knowledge and experience to run networks in a secure way - we already have too much of them.

Again, seems like it’s the users’ problem, not yours.

@pmueller

…promised to effectively reduce work for IT people. None of them ever did.
…and nobody knows how things work without anymore.

Sure, things like CI/CD, Docker,… make things easier and users don’t have to know anymore how things work without them, but at least in my professional life they also save time and make things easier, or at least I perceive it that way.
While it would be great if every network is administrated by someone with your knowledge it simply won’t ever be the case. Even within company networks in many cases, the network is managed by someone that has just a little bit more knowledge about it than the average user. That doesn’t mean that restrictions are the solution.

@pmueller

Based on our experience, nobody is going to read those information, and if people do, they will ignore them.

True, but why is that your problem? Pointing out that you don’t offer support for issues that appear while Docker containers are running solves any potential additional support effort

I also read through some of the other feature requests like, for example, Feature Request: Easy Way to Add VPN Service and it looks like you already made up your mind on deciding what users should be able to do. Personally, I think that’s the wrong way to go, but I respect your position. I guess, it’s clear that you won’t accommodate this feature request, so I won’t take up any more of your time.
Thanks again for taking the time to reply to my initial message and for providing quite a lot of additional information.