Re: Improving security for pkgsrc

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

On Tue, Jul 21, 2015 at 02:07:15PM +0200, Joerg Sonnenberger wrote:
> On Tue, Jul 21, 2015 at 01:05:42PM +0200, Pierre Pronchery wrote:
> > 			Hi,
> > 
> > On 07/19/15 17:12, Joerg Sonnenberger wrote:
> > > On Sun, Jul 19, 2015 at 01:50:36AM +0200, Pierre Pronchery wrote:
> > >>> Now I am not arguing that it doesn't make a certain class of attacks
> > >>> more harder. But the main point is that it is at most security in depth.
> > >>> It does not prevent exploits, it just makes them harder.
> > >>
> > >> It *mitigates* them.
> > > 
> > > Privilege separation, when done correctly, mitigates an exploit.
> > > Stack protector as mentioned above doesn't for many deployment
> > > scenarios. Once the canary has been guessed, the exploit is as
> > > devastating as originally.
> > 
> > Mitigate:
> > 1. (transitive) To reduce, lessen, or decrease.
> 
> Thanks for the dictionary. I have one too.
> 
> > Privilege separation is one technique to achieve this, which can be
> > combined with a number of other techniques to further reduce the attack
> > surface. A lot of bugs that would be exploitable fall short of actual
> > code execution *because* one or more mitigation techniques help
> > preventing it.
> 
> No, you are either confused or are unable to use proper terminology. A
> technique that does *not* reduce the attack surface by your very
> definition can not be called a mitigation. Privilege separation does
> reduce the attack surface from running code as root to running code as
> unprivileged user. It does not prevent an attack, but it reduces the
> impact.
> 
> > Guessing the canary as you say typically requires another bug again,
> > like an information leak. It makes the whole thing harder, more
> > expensive for the attacker. Attackers do have a budget too. We are
> > wasting ours here.
> 
> This is bullshit. Guessing the canary can literally be a brute force.
> No other bug is needed. This is the same way attacks again bad ASLR can
> be done etc. Whether the effective security is 32bit or 16bit is
> somewhat ephemeral for this discussion. Stop calling it a code
> mitigation technique. It is not. If anything, it is a hardening
> technique. It makes it more difficult to exploit something successfully,
> but it doesn't change the *impact* of such an exploit.
> 
> Joerg

Joerg, that's plain bullshit and FUD on your part.

Just because SSP isn't 100% perfect doesn't mean it doesn't help.

I don't know why you're so rigid and hell-bent on proving that, *by itself*,
ssp isn't a perfect counter-measure.

Yes, we *all know that*.   It's part of a series of checks that *do* catch
some bugs.

SSP, pie, randomization, W^X, they're all part of a chain of things that
make things MORE difficult for hackers.

Yes, yes, yes, let's all agree that the only way to prevent hackers from
coming in is by writing perfect code.

Now, in the real world, ssp saves people's asses. Because it gives you
"something funny" to look at and fix in logs.   It also makes badly written
software to crash, which might prompt people into fixing bugs.

(I have a long list of very badly written code that crashes thanks to ssp,
including the X server and mplayer among prominent examples)

Oh, and it actually *catches* some attempts to get in. In this day and age,
most attempts are still fairly unsophisticated. If you have to choose
between an OS that does ssp and another one that does not, going into the
!ssp one is very much easier.