On Jul 24, 2023, at 12:11 PM, Eric Sandeen <sand...@redhat.com> wrote:
And frankly that is some of my motivation to find an improvement here. A small cadre of filesystem developers are near the breaking point trying to keep up with an army of machines running syzkaller. There’s also a large flow-on effect to those running production systems and what they have to patch and at what pace. In the current model, where we enable the NTFS (or BeFS, or UFS, or HFS, or whatever) file system, every time that has some CVE, we get to release a security advisory saying “everybody go update your kernels” and for 99.99% of users, it’s code they don’t use, and don’t *want* to even ever have loaded. The CIS Hardening Benchmarks all start with “blacklist modules for file systems you don’t need”, and module blacklisting is both not an ideal name for the functionality, and not exactly a foolproof method. For a lot of users we are currently: - likely making them patch needlessly, as it’s code they don’t rely on - or training them that Important security updates aren’t actually always Important, and maybe they can not pay attention to them. I *really* dislike the latter. The clarity of “you have this software installed, there is an Important update to it, this means you must update within X time” is wonderful. One idea we’ve been throwing around is to put all the non-essential (i.e. everything but vfat and xfs) file system modules in a different subpackage, and sign the modules with a different key, and not trusting that key by default. Thus we could issue security advisories just for that subpackage, as well as clearly state the level of trust one should place in the code in question. Combine that with a libguestfs approach with a separate kernel package for its guest, and lazy people like me could probably not have to reboot their laptop/desktop as often, while simultaneously being more protected from random malicious flash drives.
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
