Re: Improving security for pkgsrc

[Marc Espie <espie%nerim.net@localhost>]

On Tue, Jul 21, 2015 at 01:49:49PM +0000, Benedek Gergely wrote:
> On Tue, Jul 21, 2015 at 03:03:05PM +0200, Marc Espie wrote:
> > (I have a long list of very badly written code that crashes thanks to ssp,
> > including the X server and mplayer among prominent examples)
> > 
> So developersi/testers/adv. users should enable it to catch more things and end users
> who don't know any better shouldn't.

Nah, wrong conclusion.   End users who don't know any better will see weird
things going on. Because buffer overflows that are caught by ssp, otherwise,
are going to modify the stack content in unpredictable way.

I will contend that a safe failure (abort) is much better than stack
corruption.

Also, twice the tests.   Disabling security mitigation techniques because
it might cause some badly written software to fail is a common fallacy.

It leads to such software not being fixed.   Put the blame where the blame is.

SSP traps come from bugs in software, plain and simple.  Fix the bugs.

The best thing we did over in OpenBSD  was to turn those mitigation
techniques on by default all the time.   Yes, things break.   But you put
just enough pressure for people to fix it.

What you want to do is turn those mitigation techniques into knobs that you
can twiddle.  You know what that knob is called ? It's called "allow bugs
in the software you run to make things behave in unpredictable ways".
Instead of "hey, let's make sure this bug doesn't spill over random memory".

That's pretty obvious to me.   Especially for mission-critical software.
I don't want software to keep running  after it's been proven *IT IS
CORRUPTING MEMORY*.  Which is basically what a failed ssp check says.