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

Re: Linux 3.2 in wheezy

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


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

Reply to: