Re: Linux 3.2 in wheezy
(adding few CC:s to keep track on the bug) On dim., 2012-01-29 at 21:26 +, Ben Hutchings wrote: On Sun, 2012-01-29 at 20:57 +0100, Yves-Alexis Perez wrote: On dim., 2012-01-29 at 18:22 +, Ben Hutchings wrote: Featuresets --- The only featureset provided will be 'rt' (realtime), currently built for amd64 only. If there is interest in realtime support for other architectures, we may be able to add that. However, we do need to consider the total time taken to build binary packages for each architecture. If there are particular container features that should be enabled or backported to provide a useful replacement for OpenVZ or VServer, please let us know. We cannot promise that these will all be enabled but we need to know what is missing. So in the end what are the reasons for not trying the grsecurity featureset? #605090 lacks any reply from the kernel team since quite a while, and especially after answers were provided to question asked. You already know the main reason: Feature-wise, Brad Sprengler and the PaX team still add stuff, like the gcc plugins or hardening features like symbols hiding, fix bugs (for example in RBAC code), while few of them reach mainline. I realise that the mainline Linux developers have sometimes been unreasonably resistant to these changes and I'm not intending to assign blame for this. But practically this means that we have to either carry the featureset indefinitely or disappoint users by removing it in a later release. (See the complaints about removing OpenVZ in wheezy despite 4 years' advance notice of this.) I understand this, and I still see the grsec featureset as a valuable project. Indeed, reducing the diff wrt. upstream in Debian kernel is an important goal (especially considering the time involvement). Now, I still think having a hardened Debian kernel inside the distribution is helpful and needed for some people (some of them have said so on the bug report, some other directly told me). I can continue providing kernels for stable and sid outside of Debian, but that means it's painful to find them, so less people will use it. I'm sure I don't have to remind people, but having a hardened kernel can buy you some time when some vulnerabilities are found in the kernel, like the /proc/pid/mem one (even when it does not prevent completely the vulnerability, it can prevents the exploit to be successful, for example). It also appears that you never had any response to your question to upstream about minimising the patch set. Indeed. Brad, I'm not sure if you received the initial mail, so if you have any comment… Not doing anything is indeed a way to just get rid of the question, but I would have at least appreciated a definitive answer on the bug rather than via the dda mail. I'm sorry about that; it completely slipped my mind as there have been no discussions about it for some months. Well, the last mail from the kernel team on the bug was indeed months ago (nov 10th afaict), but I kept adding info and replies since. Anyway, thanks for your answer. Regards, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Re: Linux 3.2 in wheezy
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
Re: Linux 3.2 in wheezy
On Mon, 2012-01-30 at 11:05 +0100, Yves-Alexis Perez wrote: (adding few CC:s to keep track on the bug) On dim., 2012-01-29 at 21:26 +, Ben Hutchings wrote: On Sun, 2012-01-29 at 20:57 +0100, Yves-Alexis Perez wrote: On dim., 2012-01-29 at 18:22 +, Ben Hutchings wrote: Featuresets --- The only featureset provided will be 'rt' (realtime), currently built for amd64 only. If there is interest in realtime support for other architectures, we may be able to add that. However, we do need to consider the total time taken to build binary packages for each architecture. If there are particular container features that should be enabled or backported to provide a useful replacement for OpenVZ or VServer, please let us know. We cannot promise that these will all be enabled but we need to know what is missing. So in the end what are the reasons for not trying the grsecurity featureset? #605090 lacks any reply from the kernel team since quite a while, and especially after answers were provided to question asked. You already know the main reason: Feature-wise, Brad Sprengler and the PaX team still add stuff, like the gcc plugins or hardening features like symbols hiding, fix bugs (for example in RBAC code), while few of them reach mainline. I realise that the mainline Linux developers have sometimes been unreasonably resistant to these changes and I'm not intending to assign blame for this. But practically this means that we have to either carry the featureset indefinitely or disappoint users by removing it in a later release. (See the complaints about removing OpenVZ in wheezy despite 4 years' advance notice of this.) I understand this, and I still see the grsec featureset as a valuable project. Indeed, reducing the diff wrt. upstream in Debian kernel is an important goal (especially considering the time involvement). Now, I still think having a hardened Debian kernel inside the distribution is helpful [...] I agree and I would like to see hardening of *all* our configurations, where the performance cost is not too much. That's going to protect all our users rather than just people who seek out a special paranoid configuration. Ben. -- Ben Hutchings Lowery's Law: If it jams, force it. If it breaks, it needed replacing anyway. signature.asc Description: This is a digitally signed message part
Re: Linux 3.2 in wheezy
[Brad Spengler] 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. I hope you aren't complaining that the Debian kernel team doesn't include your patch, and also complaining that Debian kernel team includes too many patches, in the same email. Probably that isn't what you tried to say, but that's kinda what it sounded like. Peter -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120130154049.ga2...@p12n.org
