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.
1 Like
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
2 Likes
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):
- STORJ Node (to benefit from HDDs that I’m not using and basically make a small profit from having my ipfire run 24/7)
- Pi Network Node
- PostgreSQL (to host my PokerTracker4 DB)
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
- users will stumble across bugs or want additional features, causing additional “support load” here
- 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.
(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:
- I am not the one who decides which features are going to be implemented in IPFire and which are not. Thereof, my posts above represent my personal opinion, which may or may not differ from those of the entire IPFire development team. Perhaps @ms, @arne_f et al. have a (different) opinion on this.
- The idea of making distributions more secure by providing less “knobs” to the users to change things is not my own nor was it invented by the IPFire project. Instead, the most popular example of this is OpenBSD (I unfortunately can only refer to this paper at the time of writing), where for example CPU vulnerability can only be enabled or disabled (with an exception to disabling SMT) in general, but not for each individual vulnerability.
At IPFire, we believe this principle works and therefore aim to achieve reasonable defaults. Perhaps this explains some of my statements written the post(s) before. - Oh well, the VPN provider debate…
It was surprisingly hard to elaborate to some users why they actually do not want to use a commercial VPN provider themselves, which is why we are not going to implement that functionality. Of course, nobody wants to see his/her opinion being proven wrong…
- Which leaves me with saying “thank you” for being willingly to discuss this feature request with me the way you did. I hope my replies were not too grumpy.
Thanks, and best regards,
Peter Müller
1 Like