On lun., 2012-01-30 at 14:08 +0000, Ben Hutchings wrote: > 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 +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 > [...] > > 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. So I think it's perfectly clear that nor Debian nor Grsecurity are really interested in Debian shipping a Grsecurity kernel. I find that sad, because I do think there are users of both which would benefit from that, and not only people who seek out a special paranoid configuration. Anyway, I'll keep updating the current setup for interested people, but without any interest from either party, that definitely looks like a dead end. Regards, -- Yves-Alexis
Attachment:
signature.asc
Description: This is a digitally signed message part