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