(adding few CC:s to keep track on the bug) On dim., 2012-01-29 at 21:26 +0000, Ben Hutchings wrote: > On Sun, 2012-01-29 at 20:57 +0100, Yves-Alexis Perez wrote: > > On dim., 2012-01-29 at 18:22 +0000, 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
Attachment:
signature.asc
Description: This is a digitally signed message part