> Indeed. Brad, I'm not sure if you received the initial mail, so if you > have any comment???
It looks like there were quite a few messages I wasn't involved in ;) Regarding minimizing the patchset, we do that already where we see opportunities to do so. We used to carry a large constifying patch which has now been replaced with a gcc plugin. Likewise with the kernel stack clearing feature. As far as gutting the patch for whatever features someone not involved in the project thinks are the only ones necessary (I saw a few posts in the thread asking for that) -- I don't think it's a good idea and I'm not interested at all in assisting that. If we're going to be in the business of telling other people what to do with their free time, might I suggest that Debian improve its userland hardening so that it's not in last place? As a Debian user myself, I can assure you that no one cares about a miniscule performance hit from PIE on i386 in su/passwd. There's no reason not to have these privilege boundaries hardened -- and very disappointing for us as MPROTECT/ASLR/GRKERNSEC_BRUTEFORCE would have provided an effective deterrent against exploitation of the /proc/pid/mem vuln were it not for distros' userland hardening being asleep on the job. That failure will continue to bite users. Frankly it makes more sense for me to offer .debs myself than to deal with a bureaucracy and non-standard kernel in Debian. It contains who-knows-what extra code, and I doubt anyone looked at any of it to see if it allows for some way to leak information I prevent against a vanilla kernel, or a way to bypass any other existing protection. There's more to security (a whole-system concept) than just the ripping of individual features. -Brad
signature.asc
Description: Digital signature
