Re: [RFC][PATCH} 2.6 and grsecurity

[Valdis . Kletnieks]

On Tue, 17 Feb 2004 01:13:59 EST, James Morris said:
> On Mon, 16 Feb 2004 Valdis.Kletnieks@xxxxxx wrote:

> > Agreed - the only one that seems at all a *big* win is randomizing PID's
> > (and even there it probably should default a higher value for pid_max to
> > increase the search space).  But as long as I was looking at it anyhow.. :)
> 
> How is this a big win?  Looks like cargo cult security to me.

Well.. I'll tell ya.. Yes, it's not totally bulletproof security.  And yes, the
*right* thing to do is to go and fix all the userspace programs that use
predictable values of mktemp() in bogus ways. On the other hand, Fedora Core 2
Test 1 is running around 1,900+ RPMs.  That's a lot of code to audit, and Linux
doesn't have a Theo doing it.  And that's not counting any 3rd party code that
a system might have on it.  And even after that, it's often a hard sell getting
a full-blown thing like a locked-down SELinux onto a user's system - but it's
often a lot easier to sell the user a kernel that's been hardened to resist some
of the more common classes of attacks.

The PaX/exec-shield code is the same way - we all *know* that both are
defeatable given enough effort.  Why is it seen as useful?  Because it at least
locks the barn doors and makes the cattle rustler fit the cow out that tiny
window instead.. ;)

No, this won't stop a truly determined and skilled hacker.  However, it puts
a major crimp in the style of a script kiddie who's got an exploit that depends
on "we can predict the next PID to within 3 or 4".  And quite frankly, I've spent
a lot more of the last 2 decades cleaning the latter off systems than the former.

It's all about raising the bar...

> > Or they OK because they're only doing a separately distributed patch?
> 
> No.

Hmm... :)

Attachment: pgp00000.pgp
Description: PGP signature