Re: Proposal: Disable autoload of compat_xyz modules

[Joerg Sonnenberger <joerg%bec.de@localhost>]

On Thu, Aug 03, 2017 at 10:07:21AM +0200, Maxime Villard wrote:
> Le 02/08/2017 à 23:08, Joerg Sonnenberger a écrit :
> > On Wed, Aug 02, 2017 at 08:52:15PM +0200, Maxime Villard wrote:
> > > I disagree. The cost of doing a modload is low enough compared to the
> > > configuration needed to use compat_linux. Just like the command you quoted.
> > 
> > If I wanted OpenBSD, I know were to get it. There is a balance between
> > pissing off people and providing security.
> 
> In your opinion, what is pissing people off the most: having to do a modload,
> or being automatically vulnerable because some guys want to be able to do
> "make install opera etc" without typing one more command?

But it is not just a modload. It means having modules in first place,
synchronised with the kernel for starters. But that's pretty irrelevant
already.

> > If you want to minimize the
> > attack surface at all cost of *your* system, you are free to do so.
> 
> Forgive me for feeling a little sorry for the users that are regularly affected
> by vulnerabilities in compat_linux*.

It is exactly this attitude that is the problem.

> > Disabling rarely used
> > code is one thing, disabling commonly used code is something else. Stop
> > pushing for "security" as a single goal above else. It doesn't make you
> > more credible, it just makes people shot down sensible proposal as knee
> > jerk reaction because they are waiting for the insane follow-up.
> 
> Getting credibility and recognition from someone like you, Joerg, is not
> something I particularly care about. We're not in the jungle, we're here to
> talk; people are giving their opinion, I'm giving mine. I fixed 11 of the 11
> vulnerabilities that affected our compat options these last ten years, so I do
> have my word to say when it comes to security and compatibility, just like
> everyone else.
> 
> If you want to be among people that cannot talk, you know where to go, and
> this place is called openbsd-tech.

Let me tell you a little fact of live. Security doesn't "Get the job
done". It won't pay the bill, it won't entertain the significant other
wanting by showing a movie in the evening etc. In fact, it is more likely
to be a hassle for either. Of course, a security problem can also mean a
lot of work, but that depends on just as many other factors. Just
because a change improves security doesn't make it good. Especially if
it stops people from using the system or forces them to jump through
hops. There have been many instances lately of "Let's make the system
more secure by turning on X by default" lately, most not even triggered
by you. Many of those cases have broken a lot of software people care
about, often in subtle ways. PaX mprotect and ASLR for example.
It doesn't help that there is a strong separation between those pushing
for the features to be enabled by default and those having to deal with
the fallout.

Now, it doesn't matter what you think of my opinion. What *should*
matter though is what I tried to explain and what you complete ignored
again. If the first reaction to many of your proposals is "stop breaking
things", it means that you have at the very least a communication
problem. NetBSD works on the principle of building a consensus with
arbitration by core when necessary. It doesn't help the process if there
is a neagtive majority even before starting reading the proposal.

Joerg