It's on my todo list to create hardening scripts for rhel/centos 7. I created them for v6. http://github.com/simontek/

Matthew Conley

-----Original Message----- From: centos-devel-bounces@centos.org [mailto:centos-devel-bounces@centos.org] On Behalf Of Tim Sent: Thursday, May 07, 2015 4:45 PM To: The CentOS developers mailing list. Subject: Re: [CentOS-devel] [SIG Hardening] hardening classes

I found this: https://highon.coffee/blog/security-harden-centos-7/

Nice guide to harden the system. These things could be put into the classes.

Regards Tim

Am 2. Mai 2015 21:38:10 MESZ, schrieb Tim lists@kiuni.de:

Hi all, I know this SIG is still founding, but I like to discuss classes of hardening. I imagine security assessment classes (SAC) like: SAC1: low SAC2: middle SAC3: high SAC4: very high Every selective measure (e.g. disabling user list) could be put into these classes where every class depends on the underlying one (2 on 1, 3 on 2, etc.) What's your opinion? Regards Tim

________________________________

CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel

On Thu, 2015-05-07 at 20:48 +0000, Conley, Matthew M CTR GXM wrote:

It's on my todo list to create hardening scripts for rhel/centos 7. I created them for v6. http://github.com/simontek/

Matthew Conley

-----Original Message----- From: centos-devel-bounces@centos.org [mailto:centos-devel-bounces@centos.org] On Behalf Of Tim Sent: Thursday, May 07, 2015 4:45 PM To: The CentOS developers mailing list. Subject: Re: [CentOS-devel] [SIG Hardening] hardening classes

I found this: https://highon.coffee/blog/security-harden-centos-7/

Nice guide to harden the system. These things could be put into the classes.

Regards Tim

Nice,

I have saved the draft for the hardening SIG a few minutes ago [0], if there are anything will you like to be added let me know. I believe that Leam has the scripts for RHEL/CentOS 5; so the SIG will aim to support all supported version of CentOS, therefore individual repos (5/6/7) will be required.

When the CentOS board member (Karabir) is available we can all meet to discuss the goal of the SIG together with the future plans and who will be maintain what.

Thoughts?

[0] http://wiki.centos.org/SpecialInterestGroup/Hardening

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.

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?

Leam

This would be typical case for hardening classes as I have suggested in my initial mail I guess.

Regards Tim

Am 8. Mai 2015 17:17:47 MESZ, schrieb "Ezequiel Brizuela [aka EHB or qlixed]" qlixed@gmail.com:

2015-05-08 8:01 GMT-03:00 Leam Hall leamhall@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@centos.org http://lists.centos.org/mailman/listinfo/centos-devel

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@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@centos.org [mailto: centos-devel-bounces@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@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@centos.org http://lists.centos.org/mailman/listinfo/centos-devel

On 05/11/2015 08:20 AM, Conley, Matthew M CTR GXM wrote:

I was meaning STIG's. http://iasecontent.disa.mil/stigs/zip/Apr2015/U_RedHat_6_V1R7_STIG_SCAP_1-1_... http://iase.disa.mil/stigs/scap/Pages/index.aspx

I ended up creating scripts that address most of the issues that are listed above.

There's an ansible project which does this. This was demoed at DevOpsDays Austin last week. The slides and links are available at

https://www.evernote.com/shard/s373/sh/6370b157-3d2d-4c0a-9e3b-53af135c6a66/...

There's also a validation tool which 'grades' the STIG compliance associated with this.

-----Original Message----- From: centos-devel-bounces@centos.org [mailto:centos-devel-bounces@centos.org] On Behalf Of Ezequiel Brizuela [aka EHB or qlixed] Sent: Friday, May 08, 2015 5:28 PM To: The CentOS developers mailing list. Subject: Re: [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@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@centos.org [mailto:centos-devel-bounces@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@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@centos.org http://lists.centos.org/mailman/listinfo/centos-devel

---

CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel