[CentOS-devel] [SIG Hardening] hardening classes

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-0004.html>