Bug#1041552: HFS/HFS+ are insecure
Looks reasonable.
Le vendredi 21 juillet 2023 à 10:55 +0200, Marco d'Itri a écrit :
> On Jul 21, Matthew Garrett <mjg59@srcf.ucam.org> wrote:
>
> > > You are totally correct.
> > > Kernel team, please blacklist HFS/HFS+ for automounting.
> >
> > Isn't this a userland policy decision? udisks will happily trigger
> > a
> > module load for hfsplus if udev has identified it, and I don't
> > think
> > there's a trivial mechanism for the kernel to disable that. I
> > believe
>
> Yes, I was also thinking about this and I believe that you are right.
> The kernel team did this in the past for some uncommon network
> protocols, but they could do it themselves because these modules are
> autoloaded using aliases.
>
> Since I happen to be the kmod maintainer it looks like that solving
> this
> is on me. :-)
>
> Unless somebody has a better idea then then my plan is to ship in
> the
> next upload of kmod a file in /etc/modprobe.d/ which uses the
> blacklist
> directive to prevent automatically loading some file system modules.
>
> By looking at the MAINTAINERS file I have identified these file
> systems
> marked as "orphan" and "odd fixes":
>
> efs
> hfs
> hfaplus
> qnx6
> sysv
>
> affs
> ecryptfs
> jffs2
> jfs
>
> And I think that I can also safely add a few more which while
> actively
> maintained I believe are only used in a retrocomputing context or
> are
> generally uncommon anyway:
>
> befs
> bfs
> hpfs
> omfs
> qnx4
> reiserfs
> spu
> ufs
>
> Did i miss anything?
>
> I think that all of these have enough of a niche usage that it would
> not
> be an unreasonable burden for the affected users to manually load
> the
> modules when needed (ad hoc or using /etc/modules-load.d/).
>
Reply to: