Technical repercussions of grsecurity removal

classic Classic list List threaded Threaded
28 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Technical repercussions of grsecurity removal

Sven Vermeulen
Hi all,

There is a nice debate ongoing on the mailinglist [1] on the topic of
grsecurity's recent decision to no longer provide the test patches to the
public. I'd like to keep the debate on the rationale of it in that
discussion, but focus here on what we, from Gentoo Hardened, now need to do
or which direction we're going to move forward with.

[1]
https://archives.gentoo.org/gentoo-hardened/message/a06145056b167f52c079bffd9c9a51ac

The obvious step is indeed to stop further *current* development on
hardened-sources. I don't know how many additional patchsets are being
implemented in it (blueness? Zorry?) so I don't know if it means that
hardened-sources in total is done with or not.

From the online discussions I also hear that we shouldn't be referring to
grsecurity anymore (even when it was still the test patches). This means
that we need to update our wiki articles, as well as include a note that the
document is only valid until a certain time (I don't want to remove them,
for those users that still have older versions running and want to find the
documentation on it).

Now, I mentioned *current* development. Are there other improvements that we
can look at which make sense to put into hardened-sources, and are there
volunteers to help out with it?

Wkr,
        Sven Vermeulen

Reply | Threaded
Open this post in threaded view
|

Re: Technical repercussions of grsecurity removal

Sven Vermeulen
On Mon, May 01, 2017 at 09:38:43AM +0000, Sven Vermeulen wrote:
> From the online discussions I also hear that we shouldn't be referring to
> grsecurity anymore (even when it was still the test patches). This means
> that we need to update our wiki articles, as well as include a note that the
> document is only valid until a certain time (I don't want to remove them,
> for those users that still have older versions running and want to find the
> documentation on it).

This seems to be incorrect - it is only if we would continue building on top
of the latest patch set release that we need to remove the grsecurity name.

https://grsecurity.net/passing_the_baton_faq.php

So all we would need to do on the wiki pages is to mark them as deprecated
in a timely fashion.

Wkr,
        Sven Vermeulen

Reply | Threaded
Open this post in threaded view
|

Re: Technical repercussions of grsecurity removal

Daniel Cegiełka
In reply to this post by Sven Vermeulen
2017-05-01 11:38 GMT+02:00 Sven Vermeulen <[hidden email]>:

> Hi all,
>
> There is a nice debate ongoing on the mailinglist [1] on the topic of
> grsecurity's recent decision to no longer provide the test patches to the
> public. I'd like to keep the debate on the rationale of it in that
> discussion, but focus here on what we, from Gentoo Hardened, now need to do
> or which direction we're going to move forward with.
>
> [1]
> https://archives.gentoo.org/gentoo-hardened/message/a06145056b167f52c079bffd9c9a51ac
>
> The obvious step is indeed to stop further *current* development on
> hardened-sources. I don't know how many additional patchsets are being
> implemented in it (blueness? Zorry?) so I don't know if it means that
> hardened-sources in total is done with or not.

Hi,

I have already written my opinion:

https://archives.gentoo.org/gentoo-hardened/message/97ccd6d5eb7f94c3cce2ac48ed41a7bb

https://archives.gentoo.org/gentoo-hardened/message/139ab72c413b2b83e08c948b061882bf


Summing up:

* PaX is the most important part of Gentoo Hardened project
(Grsecurity, SELinux, RSBAC)

* We can't use the 'grsecurity' name, which means that fork of
grsecurity == rewriting everything with 'grsecurity' (or 'grsec')
name... (~225k LOC grsec+PaX)

* PaX (~176k LOC) is available as a separate patch (1), so we can use
it without the risk of 'grsecurity' trademark

My opinion is: we should continue to use PaX patch and keep the Gentoo
Hardened project alive.

(1)  https://www.grsecurity.net/~paxguy1/

Daniel

Reply | Threaded
Open this post in threaded view
|

Re: Technical repercussions of grsecurity removal

Andrew Savchenko
In reply to this post by Sven Vermeulen
On Mon, 1 May 2017 09:38:43 +0000 Sven Vermeulen wrote:

> Hi all,
>
> There is a nice debate ongoing on the mailinglist [1] on the topic of
> grsecurity's recent decision to no longer provide the test patches to the
> public. I'd like to keep the debate on the rationale of it in that
> discussion, but focus here on what we, from Gentoo Hardened, now need to do
> or which direction we're going to move forward with.
>
> [1]
> https://archives.gentoo.org/gentoo-hardened/message/a06145056b167f52c079bffd9c9a51ac
>
> The obvious step is indeed to stop further *current* development on
> hardened-sources.
Why not support hardened-sources while corresponding vanilla
kernels are still supported? E.g. 4.9 is a longterm branch, so we
should be able to keep hardened-sources-4.9* up-to-date with
vanilla bugfixes. This will give a nice transition period for
hardened users.

Best regards,
Andrew Savchenko

attachment0 (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Technical repercussions of grsecurity removal

Andrew Savchenko
In reply to this post by Daniel Cegiełka
Hi,

On Mon, 1 May 2017 12:24:14 +0200 Daniel Cegiełka wrote:
[...]

> Summing up:
>
> * PaX is the most important part of Gentoo Hardened project
> (Grsecurity, SELinux, RSBAC)
>
> * We can't use the 'grsecurity' name, which means that fork of
> grsecurity == rewriting everything with 'grsecurity' (or 'grsec')
> name... (~225k LOC grsec+PaX)
>
> * PaX (~176k LOC) is available as a separate patch (1), so we can use
> it without the risk of 'grsecurity' trademark
>
> My opinion is: we should continue to use PaX patch and keep the Gentoo
> Hardened project alive.
>
> (1)  https://www.grsecurity.net/~paxguy1/
Are you sure PaX patches will be updated? Because PaXTeam claims
they will not be published [1]:

"As this is a joint decision, there will be no public PaX patches
for future kernels. This is effective April 26th 2017."

Or do you suggest to support PaX with our own resources?

[1] https://grsecurity.net/passing_the_baton_faq.php


Best regards,
Andrew Savchenko

attachment0 (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Technical repercussions of grsecurity removal

Daniel Cegiełka
2017-05-01 13:00 GMT+02:00 Andrew Savchenko <[hidden email]>:
> Hi,
>
> On Mon, 1 May 2017 12:24:14 +0200 Daniel Cegiełka wrote:

> Are you sure PaX patches will be updated? Because PaXTeam claims
> they will not be published [1]:

(...)

> Or do you suggest to support PaX with our own resources?

https://archives.gentoo.org/gentoo-hardened/message/97ccd6d5eb7f94c3cce2ac48ed41a7bb

Reply | Threaded
Open this post in threaded view
|

Re: Technical repercussions of grsecurity removal

Sven Vermeulen
In reply to this post by Andrew Savchenko
On Mon, May 01, 2017 at 01:28:54PM +0300, Andrew Savchenko wrote:
> > The obvious step is indeed to stop further *current* development on
> > hardened-sources.
>
> Why not support hardened-sources while corresponding vanilla
> kernels are still supported? E.g. 4.9 is a longterm branch, so we
> should be able to keep hardened-sources-4.9* up-to-date with
> vanilla bugfixes. This will give a nice transition period for
> hardened users.

Transition to what exactly?

There is one suggestion that mentions we would join forces with other
projects "out there" to keep supporting the latest PaX patches. But this
will require knowledgeable resources with enough time to do the necessary
support on it.

In my humble opinion, this is an effort which is not to be underestimated.
Maintaining the upstream-provided patches within Gentoo is already an
endeavour, and now we're talking about even taking on the patch content
itself as well.

If we have enough volunteers to do so, then let's do it. At least we can
then have something for users to look forward to. If not, then the current
long-term branch is also the latest, and the "transition period" is to allow
users to move to a perhaps lesser kernel-hardened environment.

Wkr,
  Sven Vermeulen

SK
Reply | Threaded
Open this post in threaded view
|

Re: Technical repercussions of grsecurity removal

SK
There is Subgraph that is going to keep maintaining 4.9.X LTS branch
with grsec & there is minipli[1] that is going to forward 4.9.X LTS
branch with grsec.

Would be great to join forces to keep 4.9.X LTS alive while porting
features upstream.

1.
https://github.com/minipli/linux-unofficial_grsec/tree/linux-4.9.x-unofficial_grsec


On 05/01/2017 03:58 PM, Sven Vermeulen wrote:

> On Mon, May 01, 2017 at 01:28:54PM +0300, Andrew Savchenko wrote:
>>> The obvious step is indeed to stop further *current* development on
>>> hardened-sources.
>> Why not support hardened-sources while corresponding vanilla
>> kernels are still supported? E.g. 4.9 is a longterm branch, so we
>> should be able to keep hardened-sources-4.9* up-to-date with
>> vanilla bugfixes. This will give a nice transition period for
>> hardened users.
> Transition to what exactly?
>
> There is one suggestion that mentions we would join forces with other
> projects "out there" to keep supporting the latest PaX patches. But this
> will require knowledgeable resources with enough time to do the necessary
> support on it.
>
> In my humble opinion, this is an effort which is not to be underestimated.
> Maintaining the upstream-provided patches within Gentoo is already an
> endeavour, and now we're talking about even taking on the patch content
> itself as well.
>
> If we have enough volunteers to do so, then let's do it. At least we can
> then have something for users to look forward to. If not, then the current
> long-term branch is also the latest, and the "transition period" is to allow
> users to move to a perhaps lesser kernel-hardened environment.
>
> Wkr,
>   Sven Vermeulen
>


Reply | Threaded
Open this post in threaded view
|

Re: Technical repercussions of grsecurity removal

Daniel Cegiełka
2017-05-01 16:20 GMT+02:00 SK <[hidden email]>:
> There is Subgraph that is going to keep maintaining 4.9.X LTS branch
> with grsec & there is minipli[1] that is going to forward 4.9.X LTS
> branch with grsec.
>
> Would be great to join forces to keep 4.9.X LTS alive while porting
> features upstream.

4.9.* is not a problem, but >=4.10 requires a lot of work, and of
course there is a problem with the KSPP (links kernel.org)

https://archives.gentoo.org/gentoo-hardened/message/e0f9f37be6c5985acd2f19a316a6fee0

SK
Reply | Threaded
Open this post in threaded view
|

Re: Technical repercussions of grsecurity removal

SK
Shouldn't go to 4.10+, because it will be too much work.
Best would be to maintain 4.9 LTS and not bother with 4.10 and all that.


On 05/01/2017 04:53 PM, Daniel Cegiełka wrote:

> 2017-05-01 16:20 GMT+02:00 SK <[hidden email]>:
>> There is Subgraph that is going to keep maintaining 4.9.X LTS branch
>> with grsec & there is minipli[1] that is going to forward 4.9.X LTS
>> branch with grsec.
>>
>> Would be great to join forces to keep 4.9.X LTS alive while porting
>> features upstream.
> 4.9.* is not a problem, but >=4.10 requires a lot of work, and of
> course there is a problem with the KSPP (links kernel.org)
>
> https://archives.gentoo.org/gentoo-hardened/message/e0f9f37be6c5985acd2f19a316a6fee0
>


Reply | Threaded
Open this post in threaded view
|

Re: Technical repercussions of grsecurity removal

Daniel Cegiełka
https://wiki.gentoo.org/wiki/Hardened/Hardened_Kernel_Project

It closes the topic of our discussion.

worth reading:

http://openwall.com/lists/kernel-hardening/2017/05/01/5

http://openwall.com/lists/kernel-hardening/2017/05/02/4

this means:

* KSPP means that keeping PaX for >4.9 will be difficult and painful,
as I pointed out previously
* NSA SELinux instead PAX MPROTECT?


alternatives: RSBAC

* slow, but actively developed:
http://git.rsbac.org/cgi-bin/gitweb.cgi?p=linux-4.9.y.git;a=summary

* produkction ready

* lots of options similar to what is in grsecurity (eg. restricted
chroot in grsec and jail in rsbac):

http://git.rsbac.org/cgi-bin/gitweb.cgi?p=linux-4.9.y.git;a=blob;f=rsbac/Kconfig;h=4a6ae294d41365a5c1757503575074c89ceebb11;hb=HEAD

Reply | Threaded
Open this post in threaded view
|

Re: Technical repercussions of grsecurity removal

Luis Ressel
In reply to this post by Sven Vermeulen
On Mon, 1 May 2017 09:38:43 +0000
Sven Vermeulen <[hidden email]> wrote:

> The obvious step is indeed to stop further *current* development on
> hardened-sources. I don't know how many additional patchsets are being
> implemented in it (blueness? Zorry?) so I don't know if it means that
> hardened-sources in total is done with or not.

All patches in our current patchset
(hardened-patches-4.9.24-1.extras.tar.bz2) are grsec-related. Most of
them don't even touch the kernel code, but only the Kconfig's. So
unless we manage to maintain PaX, we can indeed kiss hardened-sources
goodbye.

By the way: When switching over to gentoo-sources, please note that it
applies some patches of its own (the genpatches.extras set, whereas
hardened-sources only applies genpatches.base). Historically, this
patchset has sometimes contained some weird (and probably totally
unaudited) code. Currently it only contains two patches which look
mostly safe, but it's probably a good idea to keep an eye on this
patchset (or perhaps  to use vanilla-sources?).

Regards,
Luis

attachment0 (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Technical repercussions of grsecurity removal

Daniel Cegiełka
2017-05-02 17:28 GMT+02:00 Luis Ressel <[hidden email]>:

> On Mon, 1 May 2017 09:38:43 +0000
> Sven Vermeulen <[hidden email]> wrote:
>
>> The obvious step is indeed to stop further *current* development on
>> hardened-sources. I don't know how many additional patchsets are being
>> implemented in it (blueness? Zorry?) so I don't know if it means that
>> hardened-sources in total is done with or not.
>
> All patches in our current patchset
> (hardened-patches-4.9.24-1.extras.tar.bz2) are grsec-related. Most of
> them don't even touch the kernel code, but only the Kconfig's. So
> unless we manage to maintain PaX, we can indeed kiss hardened-sources
> goodbye.

and, of course :)

grep -r -e paxmark -e pax_kernel /usr/portage/

Reply | Threaded
Open this post in threaded view
|

Re: Technical repercussions of grsecurity removal

Luis Ressel
On Tue, 2 May 2017 17:56:22 +0200
Daniel Cegiełka <[hidden email]> wrote:

> grep -r -e paxmark -e pax_kernel /usr/portage/

pax.?mark actually, since the eclass helper is called pax-mark. :)
I'd hold off on removing those for at least a few months, though.

Regards,
Luis

attachment0 (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Technical repercussions of grsecurity removal

Daniel Cegiełka
2017-05-02 18:02 GMT+02:00 Luis Ressel <[hidden email]>:
> On Tue, 2 May 2017 17:56:22 +0200
> Daniel Cegiełka <[hidden email]> wrote:
>
>> grep -r -e paxmark -e pax_kernel /usr/portage/
>
> pax.?mark actually, since the eclass helper is called pax-mark. :)
> I'd hold off on removing those for at least a few months, though.
>

If PAX_MPROTECT returns (KSPP?), then ebuilds will need to be
'paxmarked' again. Years of work and PaX support ends in the trash.
Now we see that there is a new level of security: user trust.

Reply | Threaded
Open this post in threaded view
|

Re: Technical repercussions of grsecurity removal

"Tóth Attila"
2017.Május 2.(K) 18:59 időpontban Daniel Cegiełka ezt írta:
>> pax.?mark actually, since the eclass helper is called pax-mark. :)
>> I'd hold off on removing those for at least a few months, though.
>>
>
> If PAX_MPROTECT returns (KSPP?), then ebuilds will need to be
> 'paxmarked' again. Years of work and PaX support ends in the trash.

I must aggree here. If there will be an alternative implementation marking
may regain its meaning. The same binaries need to be marked in some way or
another. I wouldn't simply dump it unless it would disturb some
functionality.

Regards: Dw.
--
dr Tóth Attila, Radiológus, 06-20-825-8057
Attila Toth MD, Radiologist, +36-20-825-8057


Reply | Threaded
Open this post in threaded view
|

Re: Technical repercussions of grsecurity removal

Daniel Cegiełka
2017-05-02 19:23 GMT+02:00 "Tóth Attila" <[hidden email]>:

> 2017.Május 2.(K) 18:59 időpontban Daniel Cegiełka ezt írta:
>>> pax.?mark actually, since the eclass helper is called pax-mark. :)
>>> I'd hold off on removing those for at least a few months, though.
>>>
>>
>> If PAX_MPROTECT returns (KSPP?), then ebuilds will need to be
>> 'paxmarked' again. Years of work and PaX support ends in the trash.
>
> I must aggree here. If there will be an alternative implementation marking
> may regain its meaning. The same binaries need to be marked in some way or
> another. I wouldn't simply dump it unless it would disturb some
> functionality.

Even if PAX_MPROTECT somehow comes back to the kernel, there is no
guarantee that it will be compatible with current PaX ELF header
(elf_phdata->p_flags & PF_MPROTECT) or PAX_XATTR_FLAGS
(PAX_MPROTECT==0x04000000). Next, the PaX functionality are added to
the kernel gradually: one functionality per patch (eg. PAX_USERCOPY ->
HARDEN_USERCOPY).  This means that any future solution will not be
compatible with current PaX support. Again: years of work and PaX
support ends in the trash.

Reply | Threaded
Open this post in threaded view
|

Re: Technical repercussions of grsecurity removal

Alex Efros-4
Hi!

On Tue, May 02, 2017 at 09:58:18PM +0200, Daniel Cegiełka wrote:
> This means that any future solution will not be compatible with current
> PaX support.

It doesn't means that. That may happens, or not - if someone will bother
about compatibility, for example.

I also think it makes sense to keep paxmarking in ebuilds, for now.
If not for technical reasons, then just to avoid adding more damage.
GrSec/PaX is not going anywhere, at least not immediately, there are a lot
of systems which still use hardened-sources and may continue using current
versions for long enough time - and they'll need that paxmarking for
current and new versions of ebuilds. Plus there is a non-zero chance next
solution will replace GrSec/PaX in more or less compatible way. And thus
until it became clear next solution doesn't require similar paxmarking at
same places or supporting paxmarking in existing ebuilds will require any
noticeable effort - there is no good reason to destroy something what just
works now.

> Again: years of work and PaX support ends in the trash.

Yeah, we already know you feel it this way. Any reason to repeat this
again and again? How this will improve anything?

--
                        WBR, Alex.

Reply | Threaded
Open this post in threaded view
|

Re: Technical repercussions of grsecurity removal

Miroslav Rovis
In reply to this post by Daniel Cegiełka
On 170502-10:28+0200, Daniel Cegiełka wrote:
> https://wiki.gentoo.org/wiki/Hardened/Hardened_Kernel_Project
>
> It closes the topic of our discussion.
>
And I read all the discussion in gentoo-hardened in regard.

First, I'm a user[1], and I'm trying to continue to keep safe and secure
as I used to be with grsec/PaX.

I figured out only yesterday about this almost two weeks old news, and I
guess the then 10+ days old (slightly) unmaintained kernel
4.9.24-hardened (and there won't be any updates, correct?), may have
contributed to my woes[2]:

# ls -ABRgo /usr/portage/sys-kernel/hardened-sources/
...
-rw-r--r-- 1  47449 2016-12-17 02:21 ChangeLog
...
-rw-r--r-- 1   1316 2017-04-22 18:18 hardened-sources-4.9.24.ebuild
...
#

And really since late in 2016 no more entries in the Changelog. Pls.
note that I'm only stating the facts, not complaining.

I really wish I learn myself and be able to contribute; acually I have
occasinally contributed, marginally, to the hardened project, with
testing.

> worth reading:
>
> http://openwall.com/lists/kernel-hardening/2017/05/01/5
>
> http://openwall.com/lists/kernel-hardening/2017/05/02/4

And these should not be missed:

It looks like there will be no more public versions of PaX and Grsec
http://openwall.com/lists/kernel-hardening/2017/05/04/20
( Shawn's collection of links there are an eye-opener, esp. this one
link which, to me, feels like sacrilege:
https://mjg59.dreamwidth.org/39546.html
about Karen Sandler, the executive director of the Software Freedom
Conservancy, by sly means prevented to stand for LF board )

and:
< same subject >
http://openwall.com/lists/kernel-hardening/2017/05/02/14
( where find what "is... unappealing." )

> this means:
>
> * KSPP means that keeping PaX for >4.9 will be difficult and painful,
> as I pointed out previously

> * NSA SELinux instead PAX MPROTECT?
I hope this is a joke. It looks like one, at first sight, but there are
half a dozen "NSA SELinux" instances to be found in the latest
hardened-sources.

# grep 'NSA SE' /usr/src/linux/security/selinux/Kconfig
        bool "NSA SELinux Support"
        ...
#
(where linux is a hardened-sources installation)

If hardened would be down to SELinux, I wouldn't be hardening any more.

> alternatives: RSBAC
>
...

But I saw the other link that gives me some hope:

Unofficial forward ports of the last publicly available grsecurity patch
https://github.com/minipli/linux-unofficial_grsec/tree/linux-4.9.x-unofficial_grsec

which I cloned into my machine. (And I have just spent hours trying to
fix an ebuild in my custom overlay and install it in my machine, to no
avail so far, and I'm at the end of my forbearance... A little more below.)

And I wonder:

1) Are there any guides for non-programmers how to install the:

Merge tag 'v4.9.26' into linux-4.9.x-unofficial_grsec
https://github.com/minipli/linux-unofficial_grsec/commit/bb9fb983874810ca4167430508e06975af700824?diff=unified

UPDATE (at proofreading time: Matheus, thanks! You just PGP-signed the
new tag [3], reader, skip 16 lines )

2) How can I check the integrity? I can:

$ git tag --verify v4.9.26
object d071951e08ee23cd725c2336d7ab4582bb93b0af
type commit
tag v4.9.26
tagger Greg Kroah-Hartman <[hidden email]> 1493825816 -0700
...
$

but I can not verify Mathias Krause's commit. Pls. minipli, can you
start PGP-signing... [cut more text, because you have :) ]

(Continue reading, isues left here, this is the "little more below"
I mentioned above.)

The README.md is plain readme from the kernel, no mention of grsec at
all...

Where do I get some tips how to install? I do have the git sources, they
verify fine... I will, hopefully, keep strong and keep trying, but I'm
not so very sure I am able to craft an ebuild that would work and that
would install with the local git linux-unofficial_grsec repo...

I suspect the [2] below was because my kernel wasn't updated... and I do
feel a little insecure at this time...

---
[1] but I can understand the issues the developers have. I have some
        understanding of programming, and the politics with and around FOSS
        is easy to understand, given time and info.

[2] Strange script planted with Bash
    https://www.croatiafidelis.hr/foss/cap/cap-170504-strange-bash/
        and:
        Inconsistent behavior in my Gentoo OS instance
        https://lists.gt.net/gentoo/user/325985#325985

[3] $ git tag --verify v4.9.26-unofficial_grsec
    object bb9fb983874810ca4167430508e06975af700824
    type commit
    tag v4.9.26-unofficial_grsec
    tagger Mathias Krause <[hidden email]> 1494181910 +0200
   
    This is the unofficial forward port of grsecurity-3.1-4.9.24-201704252333.patch to v4.9.26
    gpg: Signature made Sun 07 May 2017 20:32:02 CEST
    gpg:                using RSA key 7585399992435BA4
    gpg: Good signature from "Mathias Krause <[hidden email]>" [unknown]
    ...
    Primary key fingerprint: 7629 8B5B B60E DAD2 1B36  2E66 7585 3999 9243 5BA4

Regards!
--
Miroslav Rovis
Zagreb, Croatia
https://www.CroatiaFidelis.hr

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Technical repercussions of grsecurity removal

Luis Ressel
Hi,

I don't have much to add, but I'd like to clear two misunderstandings
here:

On Mon, 8 May 2017 20:08:07 +0200
Miroslav Rovis <[hidden email]> wrote:

> And really since late in 2016 no more entries in the Changelog. Pls.
> note that I'm only stating the facts, not complaining.

AFAIK the Changelogs aren't updated anymore (in the whole gentoo tree).

> > * NSA SELinux instead PAX MPROTECT?  
> I hope this is a joke. It looks like one, at first sight, but there
> are half a dozen "NSA SELinux" instances to be found in the latest
> hardened-sources.
>
> # grep 'NSA SE' /usr/src/linux/security/selinux/Kconfig
> bool "NSA SELinux Support"
> ...
> #
> (where linux is a hardened-sources installation)
>
> If hardened would be down to SELinux, I wouldn't be hardening any
> more.
SELinux isn't a patch applied by hardened-sources, it's a subsystem of
the mainline kernel. grsec was really the only significant difference
between hardened-sources and gentoo-sources.

Regards,
Luis

attachment0 (849 bytes) Download Attachment
12