Mailinglist Archive: opensuse-factory (602 mails)

< Previous Next >
Re: [opensuse-factory] Re: [PLEASE SPEAK UP] Disabling legacy file systems by default?
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@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-factory+owner@xxxxxxxxxxxx

< Previous Next >
List Navigation
This Thread
Follow Ups