Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Grsecurity: What will happen to Gentoo Hardened now ?
View unanswered posts
View posts from last 24 hours

Goto page Previous  1, 2, 3  Next  
Reply to topic    Gentoo Forums Forum Index Kernel & Hardware
View previous topic :: View next topic  
Author Message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 43210
Location: 56N 3W

PostPosted: Sat May 27, 2017 11:54 am    Post subject: Reply with quote

tholin,

Thank you for the links. The real answer appears to be nobody knows until its tested in court and its not Open Source Security that carries the can, its the individual subscribers.
They use the GPLed derived code, so distribution of the sources is their problem.

It puts Open Source Security in the clear and their subscribers in a very difficult position.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
h4rdened
n00b
n00b


Joined: 13 May 2017
Posts: 14

PostPosted: Sat May 27, 2017 5:40 pm    Post subject: Reply with quote

Well... If there is not plan to give individual access for a reasonable price, I will have to considers the KSPP project, the Gentoo hardened team have any plan to move from grsecurity to KSPP or any other solutions of hardened kernel ?

About grsec, A nice move could have be done is giving every month 1 patch of Grsecurity dated of the previous month (Example: febuary 1, release for the public of the patch dated of 1 January...), with some improvement of their way to receive donation from the community (and why not with less tech / options of Grsecurity than the commercial patch)...

Closing fully the access for individual, that's cannot afford their company quote, it's just another disappointment... And another greatest thing removed from the commun people...

This message is just my opinion, I still have a high respect for the grsec team
Back to top
View user's profile Send private message
1clue
Advocate
Advocate


Joined: 05 Feb 2006
Posts: 2549

PostPosted: Sat May 27, 2017 8:01 pm    Post subject: Reply with quote

NeddySeagoon wrote:
1clue,

How does that work with the GPL?

I buy say a Linux based network appliance, that's full of binaries. The vendor has to give me the GPL sources if I ask.
In practice, they tend to give me a list of links.

If the network appliance usur the hardened patch set, its a derived work of the kernel and therefore cover by the GPL.
I can see a contradiction there but not a resolution.


That's the rub.

I write commercial software that relies on some open source software. Depending on the licenses involved (GPL for example) you have to be extremely careful about your dependencies. You can't statically link GPL code into non-free code, for example.

In this case we have a kernel which is GPL, and they're modifying it and not allowing redistribution. The way I read the license that's a broken contract and they no longer have the right to use the kernel, or alterately their entire project becomes GPL whether they want it to be or not.
Back to top
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 13855

PostPosted: Sat May 27, 2017 11:36 pm    Post subject: Reply with quote

There seem to be two major camps for how this interacts with the GNU General Public License.

Camp #1 says that the "No additional restrictions" provision of the GPL flatly forbids what Open Source Security is doing here.

Camp #2 says that the "No additional restrictions" provision only prohibits Open Source Security from compelling recipients to take, or refrain from taking, any particular action. Thus, Open Source Security cannot demand advance notice of intent to redistribute, nor demand that recipients give money to Open Source Security as a consequence of the recipient's actions. Under this interpretation, Open Source Security cannot extract additional money, whether as a fee, a penalty for breach of contract, etc. from the recipient. However, Open Source Security can, and has declared their intent to, sever business ties with, and refuse to initiate any new contracts with, anyone who dares to exercise their redistribution right under the GNU General Public License. Thus, as a practical matter, recipients can redistribute the patch, but only if they are willing to see their support contract canceled and blacklisted. No court will impose additional sanction on them, so there is "No additional restriction" on their exercise, under this view.

As for which camp is right, that depends on how a court rules.
Back to top
View user's profile Send private message
1clue
Advocate
Advocate


Joined: 05 Feb 2006
Posts: 2549

PostPosted: Mon May 29, 2017 4:26 am    Post subject: Reply with quote

Frankly I think I'm firmly in camp #1.

I've used hardened kernels for years now, and never really thought to look at what they're doing. I was thinking, ok this is a patch set that gets applied to a kernel. The sources were available in Gentoo, so that was the end of the thought process for me.
Back to top
View user's profile Send private message
h4rdened
n00b
n00b


Joined: 13 May 2017
Posts: 14

PostPosted: Mon May 29, 2017 12:55 pm    Post subject: Reply with quote

Far from me the idea to belittle anyone but, it is really important to point if, Open source security is broking the term of the GPL license or blaming the Grsecurity for stopping any release of their free public patch release or open a debat about technical dev part of their work...

facts is :

- Grsecurity have from far, the best security features for Linux (public knowledge at least). As for today and probably for at least the next few years, nothing will be equal of their tech.

- Grsecurity saw with 10 to 12 years in advance, the risk of the memory bug while we are just getting awake (since 2010 / 2012 ?) about this major treath

- Grsecurity did not stole, plagiarism their security tech, they own it and can do whatever they like with their work.

- Grsecurity gave their work for free without getting back a fair compensation from the community

We can waste our time with meaningless discussion, but those just buried faster and for sure any chance to get a deal with Grsecurity about a free and public release of the patch.

Intel could be the trigger, Google or whatever big scumbag corporate that aim their activity to increase their profit, by stealing, corrupting or broking law / human right... But the hard truth is the real responsible of the actual situation today, is the community itself.

Let me be more specific, when I say community, I do not speak for the dev of the differents hardened project (Like Gentoo, Debian, Arch...), the few generous donators or any other people who have contribute to Grsecurity in any way. I target the user, including myself, who just enjoy their work without thinking one day, the music will end.

If there is any chance to fix our mistake, it is right now, let's focus on the hope that Grsecurity team can accept to give to the public, a piece of their work, on a basis of an uniq release monthly of the testing patch, in exchange of the requirement they need or want.

First we must known if they are willing to offer or open minded about the free public release testing patch, at least, for the next 5 years.
Second, we need to known the budget required

I hope a door is still open, errors of judgment is a human behavior, if they can let us one chance, I'm sure it will be well taken. Their work are uniq and even at this time, the last public release of their testing patch will provide a high security that nothing can offer, for the next few years, it won't be forever, as soon this situation will be solved, the better it will.

For finish, if there is no chance, even by giving them millions of dollars, to see a future free and opensource release of their security tech, it will be a big regress for the public security IT and will affect numerous people who are badly depending on Grsecurity.
Back to top
View user's profile Send private message
chithanh
Developer
Developer


Joined: 05 Aug 2006
Posts: 2152
Location: Berlin, Germany

PostPosted: Mon May 29, 2017 1:43 pm    Post subject: Reply with quote

tholin wrote:
but that also makes it infeasible for companies to use the grsecurity patches in user products. That's a pretty big limitation on the usefulness of grsecurity.
I don't see why selling products containing grsecurity kernels should be infeasible. Just sell the grsecurity subscription along with your product.
Back to top
View user's profile Send private message
khayyam
Watchman
Watchman


Joined: 07 Jun 2012
Posts: 6228
Location: Room 101

PostPosted: Mon May 29, 2017 3:14 pm    Post subject: Reply with quote

tholin wrote:
but that also makes it infeasible for companies to use the grsecurity patches in user products. That's a pretty big limitation on the usefulness of grsecurity.

chithanh wrote:
I don't see why selling products containing grsecurity kernels should be infeasible. Just sell the grsecurity subscription along with your product.

chithanh ... well, I would say there really isn't such a thing as a "grsecurity kernel", grsecurity is a derivative work. So, if you wanted to apply this patch to the "linux kernel" and then distribute this as part of your device, or product (router, NAS, or what-have-you) then you would be required to publish the patch as a derivative work (which would in turn violate the terms set by grsecurity).

I'm inclined to think that grsecurity are going to end up loosing if any legal action comes of this, as it seems they are painting themselves into a corner. Anyhow, personally I'm kind of in agreement with what Ant P. said above, this has all the hallmarks of a shake-down.

best ... khay
Back to top
View user's profile Send private message
chithanh
Developer
Developer


Joined: 05 Aug 2006
Posts: 2152
Location: Berlin, Germany

PostPosted: Mon May 29, 2017 6:16 pm    Post subject: Reply with quote

I mean "grsecurity kernel" the same way as "Gentoo kernel" or "Android kernel", ie. a Linux kernel with a particular vendor patchset applied.

Also I have yet to see a convincing argument why what grsecurity does is forbidden by GPL. From what I can see, all recipients of the code retain full rights under the GPL regarding the piece of code that they received. Only if they exercise certain rights, their subscription to future releases will be terminated. But GPL does not entitle anyone to receiving future releases, so no conflict there.
Back to top
View user's profile Send private message
Ant P.
Watchman
Watchman


Joined: 18 Apr 2009
Posts: 5762

PostPosted: Mon May 29, 2017 6:44 pm    Post subject: Reply with quote

I don't really think this will come to legal proceedings; GRSecurity are being slightly less illegal than the likes of nVidia and nobody's brought them to task yet.

What I see happening in the long term is KSPP upstreaming all the parts of grsec that made it interesting to people in the first place, and with no reason to continue paying, Open Source Security slowly loses its remaining customers (to the tune of their customary venomous screeching on public forums).

With the way they've been flinging shit at LWN's editors recently just for reporting the facts I hope they do go bankrupt. They act like Windows antivirus peddlers.
Back to top
View user's profile Send private message
khayyam
Watchman
Watchman


Joined: 07 Jun 2012
Posts: 6228
Location: Room 101

PostPosted: Mon May 29, 2017 8:16 pm    Post subject: Reply with quote

chithanh wrote:
Also I have yet to see a convincing argument why what grsecurity does is forbidden by GPL. From what I can see, all recipients of the code retain full rights under the GPL regarding the piece of code that they received. Only if they exercise certain rights, their subscription to future releases will be terminated. But GPL does not entitle anyone to receiving future releases, so no conflict there.

chithanh ... that is "camp #2" the "two camps" Hu outlined above. I think it would be a very difficult argument to make legally as it places the recipient in a double bind. The patch is a derivative work, if the recipient applies the patch to their product then they would be legally bound to publish it (or not be able to distribute their product), however, grsecurity has stipulated they can't do that as a condition of them continuing to receive goods. This would almost certainly be rejected, a binding contract is by necessity fulfilable (ie, you can't repay a dept with a stipulation that the recipient not cash the cheque). I don't see how grsecurity could counter such arguments, other than to say "these are our terms and conditions", which doesn't answer to the objection. Anyhow, that probably won't happen because no competent legal adviser would have their client contract with them (hence my inclination to think of this entire debacle as a shake-down).

best ... khay
Back to top
View user's profile Send private message
h4rdened
n00b
n00b


Joined: 13 May 2017
Posts: 14

PostPosted: Tue May 30, 2017 5:13 am    Post subject: Reply with quote

The following post is entirely ironic and have for purpose to reach the same level of those feeling they can freely attack/libel the Grsecurity using untruth / nonsense statement.

Quote:
What I see happening in the long term is KSPP upstreaming all the parts of grsec that made it interesting to people in the first place, and with no reason to continue paying, Open Source Security slowly loses its remaining customers (to the tune of their customary venomous screeching on public forums).


In a futuristic long term, perhaps. Upstreaming their work and making them slowly (not too slow hopefuly) lose their financial needs and since, their communication with the public is full of their venomous harmful damaging the earth and every living thing on it, we will hope that's brad or someone else in the grsec will lose one leg in a car accident. Right ?

What they are doing is hawful and the public should be aware of what are thoses peoples : Highly skilled dev's (beyond the understand of most the people), for the last 16 years, have provided to the public a free opensource patch to increase the security of the kernel, the financial compensation they received from the community and let's don't forget, their incredible number of customers + the multiples award of best security features, the countless of people who recognized their excellence, the groupie standing 24/7 in front of their office... Despite all of this, they now want more ? After 16 years of easy and lazy life ?

The entire community was dedicated to them, even one guy, one day, has found a critical bug, the CVE of the century, the bashdoor of the Grsecurity code : a false positif (very dangerous !).

Everybody will do the same : Twitter, Facebook, Google +, Skype conference, bot spam to numerous of IRC server to spray their finding in order to have a temporary success... This is harmless, it's just spray in the mind of the people that Grsecurity didn't make a proper review by letting a false positif bug in their patch release... This is critical fail of their review process, kernel stack overflows, implementation of a proper ASLR and all their other sec tech are secondary.

How dare, the grsec team, have spitting on this security researcher ? The bible of the truth, relaying information with a perfect accuracy,"The register" has written about it... Why didn't come trough their mind that giving him the opportunity to work in the grsec team, has team leader will be a beter answer ? They have everything to win, and even more, he could handle the public communication far better than Brad :

Quote:
This is the fail in the @grsecurity patch. How did this pass review? ... a security patchset has code review, right?


See ? He could even be a diplomatic person for the US gov...

Quote:
With the way they've been flinging shit at LWN's editors recently just for reporting the facts I hope they do go bankrupt. They act like Windows antivirus peddlers.


I'm correcting you on this, the antivirus (especially norton or panda) has no need of chapman since their closed source, non-free product is a no-brainer when we talk about security, they offer something that everybody known, pointless to remind or explain them about this : Antivirus protect your computer, like a helmet for a motocycle driver, you have to pay.

Until this, let's focus on the GPL licence to get something we could use against them, Autocensorship We don't need grsecurity at all, as you pointed, the antivirus. Despite his closed source and mostly oriented Windows OS only, we can use wine to run it in a Linux system, from far, a better layer of security, a gold stuff for any security system.


Last edited by h4rdened on Tue May 30, 2017 12:49 pm; edited 2 times in total
Back to top
View user's profile Send private message
chithanh
Developer
Developer


Joined: 05 Aug 2006
Posts: 2152
Location: Berlin, Germany

PostPosted: Tue May 30, 2017 8:27 am    Post subject: Reply with quote

To clear up any misunderstanding, I am not defending what grsecurity does. It goes against the idea of free and open source software. I just think that the argument that this somehow conflicts with GPL has not been substantiated.

khayyam wrote:
The patch is a derivative work, if the recipient applies the patch to their product then they would be legally bound to publish it (or not be able to distribute their product),
No, this is a common misunderstanding. The GPL does not require anyone to publish anything. You must provide recipients of binaries access to the source code under GPL with no additional restrictions, that is all.
If you sell your product only along a grsecurity subscription, then your customers will get the source code.

khayyam wrote:
however, grsecurity has stipulated they can't do that as a condition of them continuing to receive goods. This would almost certainly be rejected, a binding contract is by necessity fulfilable (ie, you can't repay a dept with a stipulation that the recipient not cash the cheque). I don't see how grsecurity could counter such arguments, other than to say "these are our terms and conditions", which doesn't answer to the objection.
I still see no conflict with the GPL. If you rephrase it: In case redistribution happens, grsecurity is no longer obliged under the contract to provide you with future releases. All parties have fulfilled the contract.

In the LWN links above, this is likened to Red Hat distributing broken out RHEL kernel patches only to paying customers, and termination clause in case redistribution of broken out patches happens. Someone over there claimed that the FSF explicitly stated such practice to be allowed by GPL, but did not provide reference.
Back to top
View user's profile Send private message
h4rdened
n00b
n00b


Joined: 13 May 2017
Posts: 14

PostPosted: Tue May 30, 2017 12:41 pm    Post subject: Reply with quote

To be clear too, I wasn't at all targeting you in my previous post : Disagree with them for some of their move, as for the "potential" conflict with GPL using remark, judgement or words that make sense is what we call freedom of speech, which should never be restricted.

But when the author spray wrong, hateful or harmful words base on his own opinion, it's no more freedom of speech but become libel.
Back to top
View user's profile Send private message
UralZima
n00b
n00b


Joined: 04 Mar 2017
Posts: 9

PostPosted: Fri Jun 23, 2017 3:04 pm    Post subject: Reply with quote

Hi people. It seems grsecurity stopped doing test patches also.
What now will happen with hardened-sources? Kernel version is now 4.11, the last update is 4.9. Maybe better to maintain a fork of grsecurity? Switching to something other is very painful.
Back to top
View user's profile Send private message
skunk
l33t
l33t


Joined: 28 May 2003
Posts: 646
Location: granada, spain

PostPosted: Tue Jul 25, 2017 6:43 pm    Post subject: Reply with quote

i'm maintaining the 4.9 hardened kernel with upstream fixes for my customers servers until 4.9 goes eol with the hope mainstream will catch up with security features...
you can download latest incremental diff here which should be applied on top of sys-kernel/hardened-sources-4.9.24.
however please consider the following warnings:
  • i'm not a kernel hacker nor a experienced c developer, the fixes i do with failed hunks are driven just by my common sense and by my poor programming knowledge
  • i consider a new incremental diff ready when the resulting kernel code builds correctly and doesn't crash my test servers (x86_64 only)
  • i'm not responsable of any damage this patch may cause (take your kittens to a safe place)
  • some fixes may be incompatible (or i'm just unable to adapt them correctly) with the hardened codebase and breaks compilation, therefore hunks as the one described below are left out and not applied
latest upstream 38 to 39 incremental diff contain this hunk which fails to apply because grsec differences:
Code:
diff --git a/arch/x86/include/asm/elf.h b/arch/x86/include/asm/elf.h
index 94aad6364b47..c152db2ab687 100644
--- a/arch/x86/include/asm/elf.h
+++ b/arch/x86/include/asm/elf.h
@@ -245,12 +245,13 @@ extern int force_personality32;
 #define CORE_DUMP_USE_REGSET
 #define ELF_EXEC_PAGESIZE      4096
 
-/* This is the location that an ET_DYN program is loaded if exec'ed.  Typical
-   use of this is to invoke "./ld.so someprog" to test out a new version of
-   the loader.  We need to make sure that it is out of the way of the program
-   that it will "exec", and that there is sufficient room for the brk.  */
-
-#define ELF_ET_DYN_BASE                (TASK_SIZE / 3 * 2)
+/*
+ * This is the base location for PIE (ET_DYN with INTERP) loads. On
+ * 64-bit, this is raised to 4GB to leave the entire 32-bit address
+ * space open for things that want to use the area for 32-bit pointers.
+ */
+#define ELF_ET_DYN_BASE                (mmap_is_ia32() ? 0x000400000UL : \
+                                                 0x100000000UL)
 
 /* This yields a mask that user programs can use to figure out what
    instruction set this CPU supports.  This could be done in user space,
which i manually applied this way:
Code:
#define CORE_DUMP_USE_REGSET
#define ELF_EXEC_PAGESIZE       4096

/*
 * This is the base location for PIE (ET_DYN with INTERP) loads. On
 * 64-bit, this is raised to 4GB to leave the entire 32-bit address
 * space open for things that want to use the area for 32-bit pointers.
 */

#ifdef CONFIG_PAX_SEGMEXEC
#define ELF_ET_DYN_BASE         ((current->mm->pax_flags & MF_PAX_SEGMEXEC) ? SEGMEXEC_TASK_SIZE/3*2 : TASK_SIZE/3*2)
#else
#define ELF_ET_DYN_BASE         (mmap_is_ia32() ? 0x000400000UL : \
                                          0x100000000UL)
#endif
however compilation fails with the following error:
Code:
[...]
  GEN     .version
  CHK     include/generated/compile.h
  UPD     include/generated/compile.h
  CC      init/version.o
  LD      init/built-in.o
fs/built-in.o: In function `load_elf_binary':
binfmt_elf.c:(.text+0x82066): undefined reference to `current_thread_info'
make: *** [Makefile:971: vmlinux] Error 1
since this hunk looks like a security enhancement and since PAX_SEGMEXEC depends on X86_32 i guess leaving out this hunk will make this kernel less secure than vanilla on a x86_32 platform with PAX_SEGMEXEC disabled, doesn't it?
anyway if somebody has a clue on how to apply this hunk to the hardened-sources, please let me know...
thank you
Back to top
View user's profile Send private message
jahun
n00b
n00b


Joined: 11 Nov 2016
Posts: 3

PostPosted: Tue Jul 25, 2017 6:52 pm    Post subject: unofficiial grsec kernel 4.9 patches Reply with quote

i found this, good looking community unnoficcal grsec git repo:
https://github.com/minipli/linux-unofficial_grsec/

maybe hardened-sources ebuilds should also use these patches

https://bugs.gentoo.org/show_bug.cgi?id=622744
Back to top
View user's profile Send private message
skunk
l33t
l33t


Joined: 28 May 2003
Posts: 646
Location: granada, spain

PostPosted: Tue Jul 25, 2017 7:28 pm    Post subject: Reply with quote

oh great! thank you for the link jahun
Back to top
View user's profile Send private message
Moonboots
Tux's lil' helper
Tux's lil' helper


Joined: 02 Dec 2006
Posts: 124

PostPosted: Fri Jul 28, 2017 11:59 am    Post subject: Reply with quote

As a long term using of gentoo-hardened on desktop with new hardware (Ryzen 7) I have been forced to move to gentoo-sources.
I agree with Anthony Basile that "it's over" in terms in being able to guarantee that the community-led initiative gsec patches is of the same quality as before.
It simply asks to much of the gentoo-hardned team. Perhaps we need to move forward keeping the hardened tool chain with a "hardened "version of gentoo-sources ?
Back to top
View user's profile Send private message
depontius
Advocate
Advocate


Joined: 05 May 2004
Posts: 3383

PostPosted: Fri Jul 28, 2017 12:38 pm    Post subject: Reply with quote

I've been running hardened-sources on my servers, but simply gentoo-sources on my clients. Recently I found Kees Cook's hardening recommendations for the regular kernel and started implementing them on my client machines. I continue to keep an eye on his pages, when I think of it. This may not be the path we want, but it may be the path we've got.
_________________
.sigs waste space and bandwidth
Back to top
View user's profile Send private message
pietinger
n00b
n00b


Joined: 17 Oct 2006
Posts: 48

PostPosted: Fri Jul 28, 2017 3:16 pm    Post subject: Reply with quote

depontius wrote:
[...] Recently I found Kees Cook's hardening recommendations for the regular kernel and started implementing them on my client machines. [...]


Do you mean this page : https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project/Recommended_Settings ?

I did all these settings before some months and learned, I have to use the "no-multilib-profile" because of "CONFIG_IA32_EMULATION is not set".
Back to top
View user's profile Send private message
depontius
Advocate
Advocate


Joined: 05 May 2004
Posts: 3383

PostPosted: Fri Jul 28, 2017 3:36 pm    Post subject: Reply with quote

pietinger wrote:
depontius wrote:
[...] Recently I found Kees Cook's hardening recommendations for the regular kernel and started implementing them on my client machines. [...]


Do you mean this page : https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project/Recommended_Settings ?

I did all these settings before some months and learned, I have to use the "no-multilib-profile" because of "CONFIG_IA32_EMULATION is not set".


I skipped that one, and kept multilib. I figure my system is better than it was.
_________________
.sigs waste space and bandwidth
Back to top
View user's profile Send private message
msst
Apprentice
Apprentice


Joined: 07 Jun 2011
Posts: 216

PostPosted: Sat Jul 29, 2017 8:03 am    Post subject: Reply with quote

Hmm, interesting read. But I am still a bit wondering what this will precisely mean for someone using the hardened-sources.

1. Hardened-source will be lagging more and more behind mainstream kernel and become terribly outdated at some point?

2. It will keep up with mainline kernel but the grsec stuff will become outdated to the point that it has to be kicked from hardened-kernel?

3. Or will the hardened-kernel simply be phased out in favour of mainline kernel and just the hardened framework will remain?

Just tying to understand as I will soon setup a new gentoo server box, so the question is bother about hardened or not any more...
Back to top
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 13855

PostPosted: Sat Jul 29, 2017 3:42 pm    Post subject: Reply with quote

The Gentoo hardened profile and Gentoo's package sys-kernel/hardened-sources are separate but related projects. The sys-kernel/hardened-sources package has an unclear future due to grsecurity ceasing publication of free patches. The Gentoo hardened profile does not depend on sys-kernel/hardened-sources (although using the two together was generally believed to be more secure than using either one alone). If you wish, you can use the Gentoo hardened profile and switch to a different kernel sources package at any time (and even switch back to sys-kernel/hardened-sources later, without changing the user profile, if you decide sys-kernel/hardened-sources is more appropriate). I would make the decision based on whether you think the Gentoo hardened profile brings value to your situation, independent of whether you believe sys-kernel/hardened-sources has any future. For that, you need to define what threats you are trying to mitigate, then examine whether any of those threats are usefully mitigated by the Gentoo hardened project.
Back to top
View user's profile Send private message
nbrogan
n00b
n00b


Joined: 15 Apr 2017
Posts: 5

PostPosted: Sat Aug 05, 2017 5:04 am    Post subject: Reply with quote

Arch Linux has switched their hardened kernel package (https://www.archlinux.org/packages/community/x86_64/linux-hardened/) to a kernel based on 4.12, with some Grsec and Pax features ported, maintained by CopperheadOS contributors (source here: https://github.com/copperhead/linux-hardened). It's currently still in a very early stage, and missing quite a bit compared to Grsec, but it is another project to keep an eye on. Ultimately I agree with the sentiment that no one will be able to maintain the current 4.9 Grsec patches to the same level of support, and thus they will eventually have to be retired, unfortunately.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Kernel & Hardware All times are GMT
Goto page Previous  1, 2, 3  Next
Page 2 of 3

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum