Messages in this thread | | | Subject | Re: [RFC][PATCH} 2.6 and grsecurity | From | Valdis.Kletnieks@vt ... | Date | Tue, 17 Feb 2004 01:48:56 -0500 |
| |
On Tue, 17 Feb 2004 01:13:59 EST, James Morris said: > On Mon, 16 Feb 2004 Valdis.Kletnieks@vt.edu 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... :) [unhandled content-type:application/pgp-signature] | |