# Grsecurity: What will happen to Gentoo Hardened now ?

## el muchacho

As you are maybe aware, Grsecurity will stop publishing its stable kernel patches to the public:

 *Quote:*   

> Therefore, two weeks from now, we will cease the public dissemination of the stable series and will make it available to sponsors only. The test series, unfit in our view for production use, will however continue to be available to the public to avoid impact to the Gentoo Hardened and Arch Linux communities. If this does not resolve the issue, despite strong indications that it will have a large impact, we may need to resort to a policy similar to Red Hat's, described here or eventually stop the stable series entirely as it will be an unsustainable development model.
> 
> (full announcement here: https://grsecurity.net/announce.php

 

As a user of Gentoo hardened, i'm wondering what will happen to the hardened package in the portage tree ??

I haven't seen any communication on this topic on the Gentoo side even though technically, right now and since yesterday, there's no more Grsecurity stable patches available to the public !

----------

## schorsch_76

According to this (german) site

http://www.heise.de/open/meldung/Linux-Verfuegbarkeit-der-Grsecurity-Erweiterung-wird-eingeschraenkt-2792474.html

gentoo will not suffer from it.

----------

## WWWW

oh man, I miss heise englisht edition. I guess time to learn German.

If these news are true then the only other option left is NSA selinux? I thought Grsecurity was Hungarian.

----------

## depontius

Read with Chrome - it will auto-translate for you.

It specifically says thatGentoo Hardened will not be affected, because it uses the development branch.  It's that stable branch that's being removed.

----------

## skunk

 *depontius wrote:*   

> Read with Chrome - it will auto-translate for you.
> 
> It specifically says thatGentoo Hardened will not be affected, because it uses the development branch.  It's that stable branch that's being removed.

 

well this is actually not true as it does affect gentoo because there won't be any long term hardened kernel like we had with 3.14.51 and 3.2.71 that are still in portage tree...

thus gentoo users can still play with the latest and hottest hardened kernel but if they want stable servers they'll need to patch their stable kernel theirself...

not a big deal if kernel patches would always cleanly apply to hardened sources...

----------

## skunk

oh my... does this definitely mean the end of the gentoo-hardened project?

----------

## rob_dot_p

 *skunk wrote:*   

> oh my... does this definitely mean the end of the gentoo-hardened project?

 

Interesting. And sad. Doesn't look like there's an obvious way around it. Could have announced it a bit sooner to give people who currently roll with the grsec testing patch more time.

----------

## lukki

Hi,

Bad news. I hope that gentoo-hardened dont die.

----------

## rob_dot_p

 *lukki wrote:*   

> Hi,
> 
> Bad news. I hope that gentoo-hardened dont die.

 

Well, a grsecurity-patched kernel, basically the core of hardened Gentoo, is off the table now. 

There still is SELinux of course but no kernel hardening is a huge difference.

----------

## nbrogan

This is terrible news. The optimist in me hopes this might lead to an increased focus on the KSPP, and the eventual inclusion of at least some of the features of grsecurity into the kernel, but I'm not hopeful. Most likely, this just means a less secure kernel for everyone who can't pay for grsecurity, which is most people, outside large corporations.

----------

## 1clue

 *nbrogan wrote:*   

> This is terrible news. The optimist in me hopes this might lead to an increased focus on the KSPP, and the eventual inclusion of at least some of the features of grsecurity into the kernel, but I'm not hopeful. Most likely, this just means a less secure kernel for everyone who can't pay for grsecurity, which is most people, outside large corporations.

 

https://grsecurity.net/compare.php

----------

## 1clue

There is more than one thread on this on the  forum right now.

I wonder what would be necessary for:

Gentoo to get the patches commercially

A small company to get the patches

An individual to get the patches.

I read all the grsecurity announcements, so I know that the primary factor here is money. I'm just curious if anyone has done some research.

----------

## Hu

Money is only the initial gating factor.  According to the commentary elsewhere, their terms currently provide that public redistribution would cancel the contract that gives access to the updates.  Unless they grant some sort of exemption, which seems very unlikely, the patches are now effectively restricted to companies that voluntarily refrain from redistribution.

----------

## deagol

I don't believe gresec will survive with the New Modell much longer. Of course they are in a better position to jude that than I and obviously they disagree... But lets see.

Keep in Kind that there is a forth method to geht the src, one very hard for their customer to control:

Buy one product using the patches and force the vendor to give you the src and then redistrubute it. So any potential customer oft theirs must be very careful where they deploy the gresec patches, to make sure nothing can be bought by anyone who may ask for the src and may even be entitled for updates... 

I suspect that makes it much less atractive to buy the subsription from them. They must know that and have a plan. Will be interesting what... 

As for today I just hope we can somehow find a way to at least maintain the current features and port them to newer kernels. But without a open community taking ober the baton some very nice security system will die.

----------

## NeddySeagoon

Its still early days.  Several projects are doing their own thing.  Such fragmentation won't help anyone.

There is at least one effort to upstream the existing (GPL) gresec patch set but naturally, that won't get new features. Well, not from the now gresec team anyway.

The fragmented organisation around 'picking up the baton' will coalesce and those with the skills and interests will take it forward.

The who what and where will not become apparent for several months.  The 4.9 kernel is a LTS kernel, so the community has until 2019 to pick up the baton and start to run.

----------

## 1clue

 *NeddySeagoon wrote:*   

> Its still early days.  Several projects are doing their own thing.  Such fragmentation won't help anyone.
> 
> There is at least one effort to upstream the existing (GPL) gresec patch set but naturally, that won't get new features. Well, not from the now gresec team anyway.
> 
> The fragmented organisation around 'picking up the baton' will coalesce and those with the skills and interests will take it forward.
> ...

 

Really what does 'upstream the existing gresec patch set' entail? Politics aside, it would be pretty much what the Gentoo team does every time they merge the patch set with a new kernel right?

I'm not sure what the reasoning has been to not merge those patches as soon as they became available. It would be interesting to see what the main kernel devs have discussed with respect to that. I haven't seen anything negative about the patches with respect to quality or security of the code.

----------

## 1clue

Realistically speaking, accepting the patches into the kernel as they had been open sourced would have saved untold hours of work for both the grsecurity team and for every distro offering a hardened kernel. Frankly if I were on the grsecurity team I would be a little bent that nobody 'upstream' bothered to do this.

----------

## mv

 *1clue wrote:*   

> would have saved untold hours of work

 

I don't have the links currently, but: It was already suggested upstream (not by the grsecurity team); Linus had commented on it and required some changes, rejected some others; grsecurity declared that they did not submit these patches and are not interested in including anything upstream.

It seems to me that the grsecurity team (or at least some persons from it) want this redundant work, because this is how they make their living.

----------

## 1clue

I'm reading some on it now.  It seems that the grsecurity team wanted an all-or-nothing arrangement.

----------

## mv

 *1clue wrote:*   

> It seems that the grsecurity team wanted an all-or-nothing arrangement.

 

But completely being aware that certain patches would never have a chance to be accepted. So this was just a handle to not ever bring anything upstream.

----------

## skunk

an intersting read that puts some light about the whole issue...

this is confirming my fears about linux going more and more mainstream: funds and credits going the wrong way, doubtful useful software being pushed down the throat by almost all distros (systemd), caring less and less about security,...

maybe i should seriously consider openbsd for my next customer's servers  :Rolling Eyes: 

----------

## h4rdened

Arrrggg... Well their decision to sell only can be understand, regarding the huge work for free they given the last 16 years.... (+ the stealing of their security tech)

Maybe if we are a lot buying the testing patch for personal use only, the price can be enough low for be affordable by anyone. Without grsecurity, hardened is dead.

----------

## 1clue

They don't have a pricing option for an individual and don't intend to ever have one. I asked.

I also asked what their minimum pricing model was, got no answer.

Further they will not authorize distribution of their source to a third party, which specifically means there will be no linux kernel compiling by users of a distro if you want hardened kernels.

----------

## NeddySeagoon

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.

----------

## tholin

 *NeddySeagoon wrote:*   

> How does that work with the GPL?

 

Lots of info in the comments here:

https://lwn.net/Articles/720983/

https://lwn.net/Articles/721848/

The consensus seems to be that Open Source Security (the company behind grsecurity) can use those terms in their contract 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.

----------

## NeddySeagoon

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.

----------

## h4rdened

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

----------

## 1clue

 *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.
> ...

 

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.

----------

## Hu

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.

----------

## 1clue

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.

----------

## h4rdened

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.

----------

## chithanh

 *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.

----------

## khayyam

 *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

----------

## chithanh

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.

----------

## Ant P.

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.

----------

## khayyam

 *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

----------

## h4rdened

 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

----------

## chithanh

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.

----------

## h4rdened

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.

----------

## UralZima

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.

----------

## skunk

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 appliedlatest upstream 38 to 39 incremental diff contain this hunk which fails to apply because grsec differences:

```
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:

```
#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:

```
[...]

  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

----------

## jahun

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

----------

## skunk

oh great! thank you for the link jahun 

----------

## Moonboots

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 ?

----------

## depontius

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.

----------

## pietinger

 *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".

----------

## depontius

 *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.

----------

## msst

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

----------

## Hu

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.

----------

## nbrogan

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.

----------

## cord

Actually, the sys-kernel/hardened-sources[deblob] is the only GPL kernel in Gentoo. The others doesn't have that USE flag.

----------

## ago

For who is interested: https://blogs.gentoo.org/ago/2017/08/21/sys-kernel-grsecurity-sources-available/

----------

