Matthew, Do you refer the same old crypto export thingie that always hit us? Or you mean as a patch for the kernel as is? As a kernel patch the option as already was mentiones is to create an alternative kernel package, so you can use it or not based on your local rules/corp standard/legal restrictions. And I will be really happy if we can offer this as an alternate kernel. Is better than no offer it at all :) El vie, 8 de mayo de 2015 16:34, Conley, Matthew M CTR GXM < matthew.m.conley1.ctr at navy.mil> escribió: > GRSec. I am on the fence for. I do like it, but do keep in mind, in > certain settings (ie Gov't) it isn't allowed. It is simpler to learn, that > said, I would have to relearn it. > > Regards > Matthew Conley > > -----Original Message----- > From: centos-devel-bounces at centos.org [mailto: > centos-devel-bounces at centos.org] On Behalf Of Ezequiel Brizuela [aka EHB > or qlixed] > Sent: Friday, May 08, 2015 11:18 AM > To: The CentOS developers mailing list. > Subject: Re: [CentOS-devel] [SIG Hardening] hardening classes > > > > 2015-05-08 8:01 GMT-03:00 Leam Hall <leamhall at gmail.com>: > > > On 05/07/15 18:32, Ezequiel Brizuela [aka EHB or qlixed] wrote: > > > I really like to participate in this SIG, I mostly want to > add a support > for grsecurity hardened kernel, this can be an option/part > of this SIG? > Grsecurity have patches as stable for the Kernel 3.2 and > 3.14 Branches, > I know that is not the same branches that currently handle > Centos7 > Kernel, so I want to put this clear for the first moment > and get your > feedback about. > > > > Ezequiel, that would be interesting. A couple of questions come to > mind. First, will it be optional? That is, can the grsecurity stuff be a > choice of someone implementing our hardening recommendations? There are > reasons, either lack of testing framework or application requirements, that > might make a CentOS user want parts of the hardening stuff without all of > it. > > > > I suppose that we can make the kernel optional, not as an addon but as a > alternative kernel, the grsecurity kernel (http://grsecurity.net/), > involves the use of pax for executable access control and have multiple > level of security preconfigured to choose, so > > > > The second question, and this is based off my lack of knowledge, > is how future open is your idea? Can it grow to cover the current kernels > as well as the 4.x series? > > > > Currently the grsecurity got 'stable' patches for: > > * 3.1-3.2.68 - Last updated: 05/07/15 > > * 3.1-3.14.41 - Last updated: 05/07/15 > > And the 'test' patches for: > > * 3.1-4.0.2 - Last updated: 05/07/15 > > > (Quick explanation of versioning: [grsec version]-[kernel vers]) > > > So we have the long term branches 3.2.x, 3.14.x, and the stable 4.x as a > test. I dunno when is going to change this from test to stable, but It will > eventually happen. > > So, if this gain some interest, I can make a draft of how we can make this > integration happen. > > > I'm going to read and recapitulate the last SIG Security mails and review > them to see actual status/next meetings to going forward with this. > > > ~ Ezequiel Brizuela - AKA QliXeD ~ > > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20150508/dccec684/attachment-0008.html>