Mailinglist Archive: opensuse-factory (602 mails)

< Previous Next >
Re: [opensuse-factory] Re: [PLEASE SPEAK UP] Disabling legacy file systems by default?
  • From: Andreas Mahel <andreas@xxxxxxxxx>
  • Date: Sat, 02 Feb 2019 22:02:56 +0100
  • Message-id: <14214917.RFqB2hbhia@mars>
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@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-factory+owner@xxxxxxxxxxxx

< Previous Next >
List Navigation
This Thread
Follow Ups