Hi Stefan- per my previous mails implementing such a change/redesign of a storage subsystem is outside of my core competencies. Implementing such a change to the Linux kernel is also outside of my core competencies and also my capabilities. It's quite rude to tell me to do something beyond my capabilities when I have previously stated that I would be doing everyone a disservice by doing so. Further, I do not need to be told what to think by Martin Wilck. I couldn't tell you the reasons behind Linux kernel design decisions because I don't design and/or implement the Linux kernel. I have yet to see documentation of this offline meeting where a secret proposal is being worked on. I am extremely disappointed in the (open)SUSE community and still await the publication of the aforementioned secret proposal. Best, Jim On Sat, 2019-02-02 at 11:18 +0100, Stefan Seyfried wrote:
Hi Jim,
Am 01.02.19 um 18:42 schrieb Jim E Bonfiglio:
Per my previous reply to Martin Wilck, I would not complain should all file systems be "made secure" however I don't think that is necessary as all file systems have already had or willl very likely have in the future a security vulnerability discovered such that work becomes necessary to correct the vulnerability.
The file systems discussed here for blacklisting are rather obscure fringe use cases, and as such they have only relatively few users (*and developers*) who will be willing and able to fix such problems.
All the "big" file systems are actively maintained and get regular reviews, audits and fixes from upstream. That's the difference.
In lieu of addressing each insecure file systems through correction or disablement, the attack surface could be eliminated instead vis-à-vis some sort of virtualized layer between the subsystem and its connecting components.
Go ahead and do that. Do not talk about it. Do it. And make sure it performs well and gets accepted upstream.
This mailing list is not really the correct place to discuss redesigning the Linux Kernel VFS layer.
In lieu of a virtualized layer between the subsystem and its connecting components, I suppose disabling the file systems would eliminate the 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.
Do it. And make sure it performs well and gets accepted upstream.
There is a reason the Linux Kernel is implemented as it is. Textbooks often say that it should be done different. But still the Linux Kernel is quite a success story.
(my signature quote fits surprisingly well today :) -- Stefan Seyfried
"For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org