Mailinglist Archive: opensuse-factory (602 mails)

< Previous Next >
Re: [opensuse-factory] Re: [PLEASE SPEAK UP] Disabling legacy file systems by default?
Hi Simon- as far as I'm aware the currently insecure file system
implementations you are seeking to disable also possess bugs and known
exploits. While my proposal would not necessarily reduce bugs in sum
total, it ought to eliminate the necessity to concern oneself with
insecure file systems which possess bugs and known exploits.

By "virtualizing" or "extrapolating" the file system subsystem, these
buggy and known exploitable file systems (pretty much all of them)
could be contained rather than be removed and/or patched. This may
provide more flexibility to users of (open)SUSE, or, the general Linux
community at large should this be implemented upstream as previously

I hope this email provides clarity.

Best, Jim

On Mon, 2019-02-04 at 14:55 +1030, Simon Lees wrote:

On 02/02/2019 04:12, Jim E Bonfiglio wrote:
Hi Simon- I would challenge you to examine the feasibility of such
containment across the entirety of the storage subsystem as this
to be a significant value add to SLES customers, not to mention
openSUSE users. As far as I'm aware it is not necessary to disable
features of a subsystem to eliminate its attack surface.

Per my previous reply to Martin Wilck, I would not complain should
file systems be "made secure" however I don't think that is
as all file systems have already had or willl very likely have in
future a security vulnerability discovered such that work becomes
necessary to correct the vulnerability. In lieu of addressing each
insecure file systems through correction or disablement, the attack
surface could be eliminated instead vis-à-vis some sort of
layer between the subsystem and its connecting components.

In lieu of a virtualized layer between the subsystem and its
components, I suppose disabling the file systems would eliminate
current risk, but does not address future risk to any sort of CVE
bulletin or other discovery regarding file system vulnerability. I
strongly recommend addressing the root cause of this attack surface
rather than reducing the size of the surface itself.

Best, Jim

Well that is also well outside my scope, Given SUSE's upstream first
policy such a set of changes would have to be developed in the
kernel before we adopted them. In SUSE / openSUSE, even if someone is
willing to completely revamp the storage subsystem and do it in such
way that doesn't cause a significant performance hit the process will
still take at least a year likely more before it reaches our kernels
which means we need to do something in the mean time of which
uncommonly used and not well maintained filesystems makes sense.

Even if it was re written it would still have bugs as any
complex software does and eventually someone would find a way to

To unsubscribe, e-mail: opensuse-factory+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-factory+owner@xxxxxxxxxxxx

< Previous Next >
List Navigation
This Thread