Hi Andreas- should I take remarks from Stefan personally? I wasn't planning to, but I suppose I could now that you mention it. I'm not familiar with this Galaxy Hitchiking Guide you mention, but I am familiar with the Galaxy Express 999: Before humanity was born to this world, the stars shone in the heavens. Long after humanity is gone, the stars will continue to shine. While they live humanity looks up to the Sea of Stars and considers its own destiny. Everyone embarks on a journey dreaming of the Sea of Stars, chasing the pictures of one's dreams endlessly. While still on the road one eventually succumbs to an eternal sleep, though there may be many kilometers yet to go. Lives terminate, lives begin- the train runs through this endless flow. It carries on its infinite tracks the hopes, the ambition, and youth of all humanity. And for one youth the train runs again today. You are correct that I lack the expertise to implement my suggested implementation as I am generally business-facing. I proposed this implementation as a proof of concept; as such, this proof of concept does not necessitate credibility as an actual production implementation. If you would like to chastise my personal credibility, I don't care. As far as I'm aware I am a customer of the (open)SUSE distribution and have raised this concern so that this concern can be attended to. How you choose to proceed with this concern is your decision. How you choose to react or respond to this concern is also your decision. If you don't want to implement this or see to it such that this is implemented, why not just say so? I have yet to see a posting of the secret proposal previously mentioned in this thread. I am disappointed in the lack of transparency offered by the openSUSE and SUSE communities at large. Best, Jim On Sat, 2019-02-02 at 22:02 +0100, Andreas Mahel wrote:
Hi Jim,
Am Samstag, 2. Februar 2019, 18:31:01 CET schrieb Jim E Bonfiglio:
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.
Don't take remarks like the one from Stefan too personal. As I see it, they are an expression of frustration about too many people offering advice which actually is none (or at least not a good one).
Looking at what you proposed, which was something along the lines of introducing "some sort of virtualized layer between the subsystem and its connecting components".
This may or may not be a good idea, however, as long as it is not backed by sufficient manpower to actually implement it, it's just that - an idea. In addition, you are stating yourself that you don't have expertise in the relevant areas of storage subsystems and kernel design. This puts the credibility of your proposal strongly in the direction of what the hitchhiker's guide to the galaxy denotes as "seemed to be a good idea at the time".
Let's assume now that we actually got some developers eager to work on what you proposed, and that your proposal actually is a way to eliminate the security risks. What timeline would you expect for this to be implemented and integrated into the kernel? I'd bet it would take quite some time - after all it fiddles with some of the core components of the system, and messing this up is just not an option. Until then, the attack surface would remain unchanged.
So even in the most optimistic case that your proposal could serve as a solution and would be implemented, it still does not solve the problem at hand. And as such, the proposal is not really too valuable in the context of this thread. Which makes it understandable when people get a bit harsh.
Ah, and one last thing: it would be nice if you could refrain from top posting, and place your replies inline instead. That's how it's done around here, and following a thread is much easier when everyone is quoting / posting by the same conventions.
/Andreas
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 :)
-- Time flies like an arrow. Fruit flies like a banana.
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org