I stumbled upon a thread in the old forum at https://forum.ipfire.org/viewtopic.php?t=14311 suggesting that Docker support would be a great addition to IPFire.
I’m in support of that request because it would add countless new features to IPFire.
I stumbled upon a thread in the old forum at https://forum.ipfire.org/viewtopic.php?t=14311 suggesting that Docker support would be a great addition to IPFire.
I’m in support of that request because it would add countless new features to IPFire.
Hi,
personally, I am against that, as running “countless features” on a firewall is a bad idea in terms of security. I am okay with some extensions we currently provide, but virtualising things on a firewall exceeds a reasonable trade-off between security and functionality.
Please consider setting up a dedicated machine in your DMZ running Docker if you need it.
Thanks, and best regards,
Peter Müller
Thanks for the reply.
Could you elaborate on why it would be bad in terms of security? Maybe I’m missing something, but the way I understand it adding Docker would allow each IPFire user to add whichever service he/she needs onto the same machine, and since those services run within their own Docker containers there shouldn’t be an added security risk? (Maybe I’m wrong here).
It would, however, save devs time since they wouldn’t need to develop certain addons anymore.
Hi,
first, Docker containers share their kernel with the host system (that’s the difference between a container and a VM), which is a huge security risk especially when it comes to kernel functionality commonly needed, such as user namespaces.
Second, running additional services on the same machine is - in terms of security - bad by principle.
(Not to mention the general discussion why those services need to run on a firewall…)
Then there is networking: Docker (ab)uses NAT by default, and while you can change networking - for example, by using the IPVLAN feature -, it still leaves you with a dynamic and quirky network setup on a system that is designed for isolating networks as best as possible.
Container environments in general and Docker in particular are fragile, interfere with other host configurations and follow a “make it work no matter what it takes” strategy, which I believe contradicts security considerations. You are absolutely free to run Docker on machines behind IPFire, but running it on IPFire creates more problems than it solves - at least from my point of view.
It would, however, save devs time since they wouldn’t need to develop certain addons anymore.
Such as? Because we would be able to put an add-on into a container, we still have to maintain it (plus maintain the container technology, which actually means extra work).
I am absolutely against allowing IPFire users to run arbitrary (i. e. untrusted) Docker containers on their systems, since this is precisely what we try to avoid when we introduced sealed kernel or are running our own packaging system.
Thanks, and best regards,
Peter Müller
And when we are talking about bad designs in general: Docker is bad design by default. Don’t use it! Better use Podman where you do not need root to run containers. You can run containers in the context of non-privileged users.
By the way @rauchenwaldc I doubt your Development Style. You are developing on a productive system? Don’t do this either. Please…
Thanks again for your reply. I really appreciate you taking the time to explain your side.
But that’s only an issue if the docker container itself is “malicious” or not?
That argument could probably be made for the majority of services that currently can be added through Pakfire?
And that’s where I disagree to some extend.
Yes, if I’d use my ipfire to protect my companies network setting up additional services on separate machines within DMZ makes sense.
However, I’m sure there are plenty ipfire users like me that use ipfire as firewall in their private network and there budgets usually are different. So buying and running dedicated hardware for everything just isn’t an option.
Giving users the freedom to decide what else they want to run would make sense IMHO.
Thanks @teejay for the tip. I haven’t heard about Podman so far, but it really looks like a great alternative to Docker.
@pmueller I get that even Podman would share the kernel with the host, but since ipfire is using a “sealed kernel” as explained in the blog post you linked I don’t see why/how that could cause an issue?
Adding Docker (or Podman) support to ipfire would leave it up to the user if/which containers a user wants to run on ipfire.
In cases like mine, where ipfire is used to secure a personal network and neither the budget nor the infrastructure exists to add new machines it would grant me and others more flexibility.
In my specific case, I’d need docker support to run the following things on the same machine (since it’s the only machine running 24/7 in my house):
Why? Wouldn’t it be enough in that case to maintain the Docker/Podman integration? It’s up to the user then to decide which container he/she installs and if Docker/Podman runs on the host I don’t understand/see why you’d need to maintain any of the images/apps that can run in those containers?
Maybe I’m wrong here, but wouldn’t the work on your end only consist of adding Docker/Podman support to the distro and in an ideal case add a section to the IPFire GUI to see which images are running + maybe (not sure if it can be done) set up a “zone” to manage which ports should be open for Docker?
Shouldn’t that be up to the user? Unless adding Docker/Podman support itself to ipfire would automatically cause security issues, it would then be up to the user to decide if/which service he/she wants to run on their machine as well.
I still believe that it would mean more flexibility for the users combined with less effort for developers. No need to verify ever docker image, simply add a confirmation dialog or huge tooltip that points out potential risks?
Overall I’m sure there are many ipfire feature requests that would be solved this way.
Hi,
no, this also applies on containers becoming compromised during their runtime.
Well, there are certainly add-ons available via Pakfire which provide functionality I would not recommed to run on a firewall. Some of them are frequently a subject of discussions whether or not we can/should/want to drop them, some are not.
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. This makes development easier and - at least in theory - debugging less hard, as we only need to know the name and version of a problematic add-on to have at least an idea about what the user is talking.
Running arbitrary containers on your IPFire system makes developing and debugging more harassed and - since publicly available container images often contain security vulnerabilities themselves - poses a security threat.
To give a more striking example: An attacker could prepare a (privileged) container with all his tools, which he only needs to download on an IPFire system. With the current situation, it is not that easy to run arbitrary 3rd party code on it, and while we assume this is possible during our security considerations, we are certainly not advising users to do so.
I am sorry to disagree. IPFire is a specialised distribution, not a generic one. The latter should provide as much freedom as possible, while the first is intended to serve a certain purpose as best as possible.
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.
This is exactly the problem: 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.
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.
No, it is not enough to provide that integration, since
(Small remark: Within the last ~ five years, I never came across any hyped technology such as containers, CI/CD, automation, etc. that promised to effectively reduce work for IT people. None of them ever did. So, today, we are running the application/network we were paid to run plus all the other cool stuff never actually being necessary to run anything, but now being obligatory because it’s cool and nobody knows how things work without anymore. Congratulations!)
As stated above, no.
We have had countless discussions on whether or not users should be allowed to disable DNSSEC validation, and we have decided not to give them the possibility for the reasons explained above.
Based on our experience, nobody is going to read those information, and if people do, they will ignore them.
I doubt it.
Thanks, and best regards,
Peter Müller
That was fast.
But wouldn’t that limit the issue to the container?
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.
But that would already require that the attacker already has access to the machine or not?
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?
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.
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.
See above, simply don’t offer support for services running in Docker containers (besides containers that you may eventually provide yourself)
Again, seems like it’s the users’ problem, not yours.
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.
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.
Hi,
thank you.
Unfortunately not really. A container is somewhat separated from its host system, but privilege escalations and breakouts are documented and - depending on your setup - can be quite easy.
To give an example: Sensitive information regarding kernel memory allocations often can be trivially obtained by running the following command as an unprivileged user or inside a container:
cat /proc/kallsyms
While the memory addresses have been zeroed out on IPFire systems mitigating this information leak, it becomes obvious that a compromised container affects the host system as such and all other containers running on it almost immediately.
Yes, but that is not the only attack vector against a Linux system unfortunately.
Just some points I want to add here:
Thanks, and best regards,
Peter Müller
Maybe the other way around is an option, run ipfire in docker along with the other services.
You may need to spend some time defining multiple networks so you can use docker-compose.
A post was split to a new topic: I’ll be exploring pfsense, opmsense and ipfire in the next few weeks…