[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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 +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.

Ben.

-- 
Ben Hutchings
Lowery's Law:
             If it jams, force it. If it breaks, it needed replacing anyway.

Attachment: signature.asc
Description: This is a digitally signed message part


Reply to: