The SUSE developers have announced plans to disable outdated or little-used file systems which are compatible with the Linux kernel by default. The change is planned to be included in future releases of SLE 15-SP1 and OpenSUSE Leap 15.1.
The reason is the desire to protect the system from possible attacks carried out by connecting media with specially modified file systems that exploit vulnerabilities in their implementations.
As stated in the statement:
SUSE will blacklist a number of legacy file systems and / or less used by default in SLES for security reasons.
The proposed list It can be seen here.
The question now is whether we should do the same for openSUSE.
My guess is that while the above list is probably not controversial for business customers, openSUSE users may have objections to some items on the list.
Less used file systems will be blacklisted
Modules with the implementation of 21 filesystems are blacklisted and will not load by default when connecting a drive with filesystem data.
The change only affects the automatic loading of modules when mounted with automatic detection of some file system.
In any case, users should note that even if we do this, you can re-enable the file systems you need by simply commenting out the lines in the blacklist file.
The user can still manually mount the filesystem using the mount command, by explicitly specifying the filesystem type (for example, "mount -t jfs"), or by loading the required module (for example, "modprobe jfs").
It is noted that for many filesystems in support of a blacklist for a long time it just comes down to maintaining compatibility with the kernel API And the code will never be audited and may contain vulnerabilities that can be exploited by connecting the malicious external drive.
The F2FS file system, used in mobile device flash drives, was actively listed FS locked by default, including the Samsung F2FS file system.
The reason for blacklisting F2FS is the lack of a mechanism to determine the file system version on this file system, which does not guarantee preservation of compatibility during backporting security fixes.
Currently the composition of the black list is as follows:
- ADFS
- goodbye
- bfs
- before
- Cramps
- efs
- EROFS
- exofs
- Freevxfs
- f2fs
- hfs (hfsplus module autunun saved)
- hpfs (OS/2)
- jffs2
- JFS
- minix
- nilfs2
- qnx4
- qnx6
- sysv
- UBIFS
- ufs
Other file systems are also in focus
Besides these also plans are in place to add omfs and ntfs filesystems to list (ntfs hasn't been developed for a long time, so currently ntfs-3g should be used)
It's not that NTFS isn't widely used; Only the only attention that
ntfs kernel module has been seen since 2007.
Although the idea from a quick and practical point of view is not bad, the reality is that It has started to generate a discussion since it does not seem like a great idea after all.
And it is as commented, in terms of local file systems, the vast majority of users use:
ext2 / 3/4, xfs, btrfs, and reiserfs. Whereas OCFS2 and GFS2 are common enough that you don't want to blacklist them.
The rest are for compatibility with old or rare operating systems, for pure flash media (that is, without FTL), or have other maintenance issues (f2fs). Are there users out there for any of these?
I'm sure there are a handful. I just don't think it's worth leaving the one that the vast majority of users can accommodate a few.