Hello *,

a while ago, we tried to enforce an "integrity" lockdown of the kernel by enabling LSM, and enforcing this mode through the kernel configuration. Ultimately, the latter was reverted due to firmware flashing rendered unusable, since direct PCI access, /dev/mem and various other sensitive functionalities were crippled by LSM.

The other day, I stumbled across https://eclypsium.com/2022/06/02/conti-targets-critical-firmware/, and would like to take this article as an opportunity to discuss the kernel capabilities we prospectively want to support in IPFire again. (A news comprehension of that article is, for example, available through https://www.bleepingcomputer.com/news/security/conti-ransomware-targeted-int....)

It is not news that ordinary threat actors are capable of deploying UEFI/BIOS rootkits. The first UEFI rootkit used in the wild was spotted in 2018, and TrickBot features such capabilities since 2020 at the latest. To the best of my knowledge, non-state backed miscreants targeting things like Intel ME in "production", however, is a new development, and certainly a worrying one.

When asked, we regularly state IPFire is not a general-purpose distribution, and anything being too far from the duties of a firewall should be run elsewhere. (In my perception, we do not state this bold enough, but let's leave that as it is for the time being.) Following this principle, I would like to see things such as the multimedia stack we currently support in IPFire 2.x go in IPFire 3.x. As for kernel capabilities and attack surface, dropping virtualisation support would cause a more noticeable improvement, but I am not sure if this is feasible even for IPFire 3.x.

However, with regards to firmware flashing capabilities, I am quite torn: On the one hand, as stated in the aforementioned report, the threat of firmware implants being deployed by cybercrooks en masse particularly _stems_ from firmware being outdated, and even sensitive environments often remain vastly unpatched. Providing IPFire users with an easy possibility of updating their firmware therefore is a good thing, presumed they actually do so. (Which I doubt, given that even after five weeks, merely 40% of all IPFire installations run on an up-to-date Core Update, according to Fireinfo. With less than half of our userbase installing updates in a somewhat timely manner, I doubt the majority of them will even consider firmware updating.)

On the other hand, if IPFire's kernel would lack abilities required to flash firmware, deployment of UEFI/BIOS rootkits and eventually Intel ME/SMM implants would be significantly hampered. From an academic standpoint, the little we support, the better.

Though, again, regarding post-compromisation activity, we have always preached that IPFire is not intended to have any 3rd party code run on it. If an attacker manages to do this somehow, it's curtains either way. More skilled threat actors are likely to bring their own toolkit.

In my opinion, making decisions for IPFire 3.x is a bit too early, with the Pakfire Build System being somewhat-ish working, and something like an 1.0 version of IPFire 3.x anticipated by the end of the year (unforeseen incidents not taken into account). However, I think it is good to have such debates on principles solved sooner rather than later, to avoid breaking changes to security concepts being introduced in production. :-)

If anybody has some thoughts and opinions to share on this front, I am happy to hear them.

Thanks, and best regards, Peter Müller