OpenSUSE Looking At Blacklisting Legacy & Less Secure File-Systems

[sysrich]

The issue is not stability but security.

I'd also like to add that f2fs is an ongoing shitshow on OpenWrt, breaking left and right on archs that are not x86, although this does not matter for OpenSUSE specifically of course.

openSUSEs three distributions include aarch64 support directly contributed to by ARM, ppc64 support directly contributed to by IBM, and there are even stirrings in the community for adding s390x and RISC-V support

so, actually multi-Arch is an additional consideration on top of those already mentioned.

[sysrich]

This choice mimics SUSE's, so maybe he wants to sue SUSE's company.

Still good luck with that.

Indeed, SUSEs enterprise documentation has long included a list of supported filesystems and I’m reasonably confident that list has never included JFS for example.

[Guest]

This blacklisting happens by adding them to a text file called /etc/modprobe.d/50-blacklist.conf

Blocking useful file systems that MIGHT cause security problems should only happen in a hardened flavor, not the normal desktop-oriented version.

[skeevy420]

This blacklisting happens by adding them to a text file called /etc/modprobe.d/50-blacklist.conf
that also currently contains a long list of other random trash drivers they don't want to enable by default.

If someone REALLY needs that specific filesystem enabled can just go and edit this file as root.

That's what made me laugh about the "write us a new OS comment" above and why I brought up Gentoo. 40 different new OSs could be written and none of them would make everyone happy.

Check out this new OS, it has 18 different stable repositories based on CPU architecture, everything is compiled using LTO/PGO/O3/Oclear on a per architecture basis and no other distribution can beat it in benchmarks, it has an awesome and sane on-my-ZSH setup, it uses cgroups & systemd for every process for increased isolation, sandboxing, & security....well fuck systemd and fuck that new OS....

Personally, there isn't any one distribution that does everything the way I'd like...not a complaint, it is what it is. I like Arch and the Arch Way. Sometimes Arch updates their repos a bit faster than they should and bad things might happen. Manjaro makes a good buffer for the times Arch updates a little too fast.

The problem with Manjaro is it is a noob distribution and it can hold a power user's hand too damn much -- it's hard for a distribution to find the right balance between ease-of-use, stability, advanced features, caters to power users, caters to new users...I'd like Manjaro without most of their tools since their kernel manager and driver tools get in my way...lol...essentially Arch with two testing repositories...we could call them Manjaro Home & Manjaro Pro.

[Guest]

They should stop auto mounting crap instead of blacklisting some useful filesystems. Just let one wonder if there is an agenda...

This. Automounting is a vulnerability that provides questionable convenience at best. GVFS is a resource hog, and it mounts file systems at incomprehensible paths which are only really usable within a graphical file manager.

[skeevy420]

Blocking useful file systems that MIGHT cause security problems should only happen in a hardened flavor, not the normal desktop-oriented version.

Um, Suse is pretty hardened by default. That's one of my favorite things about the Suse family.

[Compartmentalisation]

I imagine the emotional people here don't use OpenSUSE, or they'd be writing a more sane bug report.

[Guest]

Um, Suse is pretty hardened by default. That's one of my favorite things about the Suse family.

Basic hardening that has no impact on usability or performance is fine, but going further should be opt in. Considering they're willing to disable something as basic as file system support by default, they might as well rename themselves to Tinfoil Hat GNU/Linux.

[useless]

Geez people. It's a one line edit! Hell, they're even trying to come up with a rpm post install script to not block the one you're using (if so) as root fs.

As for F2FS: yeah, apparently by the comments in the discussion link, it's a major maintainability problem (no fs versioning? Is that true?).

EDIT: typo

[starshipeleven]

Blocking useful file systems that MIGHT cause security problems should only happen in a hardened flavor, not the normal desktop-oriented version.

"MIGHT" my ass, the listed filesystems do have open CVEs even now and given their status it may or may not be fixed any time soon. I can't speak for F2FS but I think it's a different issue there, given how it's a shitshow of breakage on other architectures.

That said, please show me how many normal OpenSUSE desktop systems routinely use "ADFS, BFS, BEFS, CRAMFS, HFS, MINIX, UBIFS, UFS, NILFS2, JFS, and F2FS. " at all. (hint: not much as you can't select them on installation)
I'm pretty sure that apart from F2FS most people here don't even know what the fuck most other filesystems even are for.

Since this is just a DEFAULT CONFIGURATION change, and no packages aren't outright removed from the repos I think it's safe to assume that anyone that is enough into Linux to actually know and care about a specific filesystem in the black list will also be able to guess or google where kernel modules are blacklisted and go remove the line blacklisting his module of choice from a fucking text config file.

Also as another guy said, OpenSUSE does ship with more hardening by default, for example the last systemd bug would not have affected it due to this hardening.

For example OpenSUSE does warn you that when you install Virtualbox you will have to enable an unsafe functionality in the OS to be able to do the USB passthrough to the VM.

This. Automounting is a vulnerability that provides questionable convenience at best.

Afaik there is no automounting by default in OpenSUSE so you should really calm yo tits.

If I plug in a drive it will ask me if I want to mount it with a notification. All mounts happening this way go into a folder in /run/media/username/drivelabel (or uuid if it has no label).