# hardened-sources going forward

## Uzytkownik

Given that grsecurity stopped releasing patches post-4.9 what is the status of hardened-sources going forward?

----------

## GSF1200S

 *Uzytkownik wrote:*   

> Given that grsecurity stopped releasing patches post-4.9 what is the status of hardened-sources going forward?

 

I too would be eager to know what the plan is.

That said, even if the project- or the grsecurity part of it- dies, I'm thankful for all the time I did have on it, and the efforts of the Gentoo hardened maintainers. Sucks for them too- they've put tons of time into this project and they're basically getting hosed upstream.

Alpine Linux forked grsecurity for their purposes I think awhile ago, though I'm not very sure of the details. I know that some features dont seem to work. For example, I cant get the deny new usb grsecurity module to work under my Alpine VM (says the sysctl value doesnt exist). Im unsure what other derivations exist- I cant get the checksec script to run for discovering grsecurity kernel configuration like I can on Gentoo. I might try building a kernel for Alpine if possible and see if I can get a bead on what security features are present. Alpine does build all packages fullrelro/canary/pie/fortify, they use PAX aslr, etc.

----------

## Uzytkownik

 *GSF1200S wrote:*   

> That said, even if the project- or the grsecurity part of it- dies, I'm thankful for all the time I did have on it, and the efforts of the Gentoo hardened maintainers. Sucks for them too- they've put tons of time into this project 
> 
> 

 

While I am not that quick to judge upstream I am sorry if I gave impression that I am anything but grateful for the hard work.

----------

## GSF1200S

 *Uzytkownik wrote:*   

>  *GSF1200S wrote:*   That said, even if the project- or the grsecurity part of it- dies, I'm thankful for all the time I did have on it, and the efforts of the Gentoo hardened maintainers. Sucks for them too- they've put tons of time into this project 
> 
>  
> 
> While I am not that quick to judge upstream I am sorry if I gave impression that I am anything but grateful for the hard work.

 

Oh no man.. I didnt mean it that way. You asked a question plenty of us who ran hardened have now.

I guess I am a little quick to judge upstream. Its gotta be hard putting over a decade in a product, giving it away for free, and only ever hearing feedback when people bitch. Still, upstream in this case hasnt always been civil either, and it has hit a number of communities pretty much all at once (Arch had a grsec kernel, Debian has one in Sid and backported to Jessie, Gentoo hardened, etc). I dont have a right to bitch though...

----------

## 1clue

History and official announcements for those of you who don't know.

https://www.grsecurity.net/announce.php

https://grsecurity.net/passing_the_baton.php

I'm curious if it's possible to get the patches on an individual basis? I emailed them to find out how much it would cost.

----------

## Jacekalex

The KSPP project remains:

https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project

 :Confused: 

----------

## nbrogan

The best possible outcome of this would be an increased focus on the KSPP and hardening the kernel from upstream, but I'm not that hopeful that will happen.

----------

## 1clue

 *Jacekalex wrote:*   

> The KSPP project remains:
> 
> https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project
> 
> 

 

https://grsecurity.net/compare.php

----------

## Jacekalex

 *1clue wrote:*   

>  *Jacekalex wrote:*   The KSPP project remains:
> 
> https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project
> 
>  
> ...

 

So far, many users and hackers have ignored KSPP, because they had Grsec / Pax with very good support in the Grsec forum.

An old saying says that "nature does not tolerate a vacuum".

----------

## depontius

 *1clue wrote:*   

>  *Jacekalex wrote:*   The KSPP project remains:
> 
> https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project
> 
>  
> ...

 

I won't dispute what the table says, but I'm also sure that the items are selected to feature GRSecurity's advantages over the others.  That said, I don't know how to create a neutral equivalent of such a table.  One other thought...  While KSPP may not be better than GRSecurity, AppArmor, or SELinux, it is better than a vanilla kernel.  As I look at its recommendations, I think I might like to consider that on my next kernel builds.

----------

## toralf

 *depontius wrote:*   

> As I look at its recommendations, I think I might like to consider that on my next kernel builds.

 +1

----------

## mv

 *depontius wrote:*   

> KSPP [...] is better than a vanilla kernel

 

Isn't it fully merged into vanilla kernel?

----------

## rip_her_APART

I feel so bad about this whole case. I don't know what to say or do   :Sad: 

----------

## Ant P.

KSPP intends to upstream code, which a responsible professional would have done all along. Beware of "security industry" people who try to sell you a cure using FUD and then run away and hide when someone points out it's poison.

----------

## Sadako

 *Ant P. wrote:*   

> Beware of "security industry" people who try to sell you a cure using FUD and then run away and hide when someone points out it's poison.

 There have been a number of major kernel exploits in recent years that were completely ineffective against properly configured grsecurity-patched kernels.

Say whatever else you want about these guys, but snake oil salesmen they are not.

----------

## roki942

Could the money trail on this actually lead beyond grsecurity?

That may be a very stupid question but I have an abundance of them.   :Laughing: 

----------

## Ant P.

 *Sadako wrote:*   

>  *Ant P. wrote:*   Beware of "security industry" people who try to sell you a cure using FUD and then run away and hide when someone points out it's poison. There have been a number of major kernel exploits in recent years that were completely ineffective against properly configured grsecurity-patched kernels.
> 
> Say whatever else you want about these guys, but snake oil salesmen they are not.

 

They are. Their entire project is addressing a non-existent threat model only a demoscene wannabe sealed in an echo chamber for 20 years could dream up. Nobody bothers writing general purpose malware that targets the Linux kernel directly (except systemd), it's a million times easier to just abuse userspace.

Nobody gives a damn about root in this century when the contents of your dotfiles have monetary value and that unsecured wordpress install is all ready to relay spam.

----------

## rob_dot_p

 *Ant P. wrote:*   

> 
> 
> They are. Their entire project is addressing a non-existent threat model only a demoscene wannabe sealed in an echo chamber for 20 years could dream up. Nobody bothers writing general purpose malware that targets the Linux kernel directly (except systemd), it's a million times easier to just abuse userspace.
> 
> 

 

Abuse userspace, like exploiting memory corruptions of processes running in userspace to achieve arbitrary code execution? 

Good thing that grsecurity helps alot with that, I guess.

----------

## Nazzy

 *Ant P. wrote:*   

> Their entire project is addressing a non-existent threat model only a demoscene wannabe sealed in an echo chamber for 20 years could dream up. Nobody bothers writing general purpose malware that targets the Linux kernel directly (except systemd), it's a million times easier to just abuse userspace.
> 
> Nobody gives a damn about root in this century when the contents of your dotfiles have monetary value and that unsecured wordpress install is all ready to relay spam.

 

Sorry to report your assumptions are pretty much false.  While userspace is certainly where they get in, privilege escalation is a good way to make sure you stay in.

Scriptkiddies might just want to pop wordpress installs and spam but not every attacker is that simplistic... the ones that are a real threat are interested in escaping whatever security you put in place and the kernel is the best vector for that.  If your goal is to escape a virtualisation or containerised environment the kernel is pretty much your only vector.

People wanting to do botting, RAT, DoS, sip fraud, etc... the kind of threat that actually hoses you beyond reinstalling your wordpress instance is the kind of threat that cares about persistence in your environment, sometimes they care about locking you out if possible, and sometimes they care about making your life miserable.

Grsec and kernel hardening isn't about protecting against the idiots that litter obfuscated shells all over your out of date php webapp, making their life harder is just a useful byproduct.

----------

## depontius

 *mv wrote:*   

>  *depontius wrote:*   KSPP [...] is better than a vanilla kernel 
> 
> Isn't it fully merged into vanilla kernel?

 

It has recommendations that I've never seen before.  I'm saying that trying those recommendations will be better than the relatively vanilla kernels I've been using.

----------

## Ant P.

 *rob_dot_p wrote:*   

>  *Ant P. wrote:*   
> 
> They are. Their entire project is addressing a non-existent threat model only a demoscene wannabe sealed in an echo chamber for 20 years could dream up. Nobody bothers writing general purpose malware that targets the Linux kernel directly (except systemd), it's a million times easier to just abuse userspace.
> 
>  
> ...

 

I guess the line you ignored went right over your head. grsecurity does absolutely nothing to address exploits in most languages: Perl, Python, Bash, PHP, Ruby, C#, Java, Javascript, C+ASAN...

----------

## 1clue

 *Ant P. wrote:*   

>  *rob_dot_p wrote:*    *Ant P. wrote:*   
> 
> They are. Their entire project is addressing a non-existent threat model only a demoscene wannabe sealed in an echo chamber for 20 years could dream up. Nobody bothers writing general purpose malware that targets the Linux kernel directly (except systemd), it's a million times easier to just abuse userspace.
> 
>  
> ...

 

Dude. It's kernel mods. Of course it does nothing to address exploits in most languages. Those exploits need to be dealt with in the language code not the kernel.

----------

## NTU

FWIW, I've been working on splitting up the Grsecurity kernel patch blob into separate files, making it easier for other people to develop and work with, as well as solve merge conflicts with kernel releases not supported by the grsecurity team.

I've also been working on splitting up the KSPP patches and backporting hardened usercopy, ASLR, and virtually mapped kernel stacks to kernel 4.4, please note this is all a work-in-progress and not complete.

KSSS (my unsupported patchset I've gathered from 4.9) is the furthest along on ARM64, but will also support ARM and x86 platforms as well.

The patch collection for my fork that I've been working on can be found here, again these are specifically for kernel 4.4:

https://github.com/NTULINUX/kernel-patches/tree/master/security_backports

The patch collection for grsecurity will be posted when it is further along. I have already contacted spender and some of his buddies and was immidiately attacked in his IRC channel. Him and his team strongly advised against me doing such a thing, I hope that my efforts though aren't the cause of the shutdown of Grsecurity as that was not my goal, but rather to make it's code base much easier to work with. I wasn't even aware of the shutdown until I saw this thread, I've been too busy working on my own things.

----------

## Hu

Generally, it's true that it does not help as much against scripting language exploits, but some of the grsecurity features focus more on making it painful or impossible to do security-unwise things.  For example, Trusted Path Execution and the chroot restrictions cause the grsecurity kernel to deny certain system calls that a vanilla kernel would allow.  In theory, these actions should never be done on a secure system.  They do err on the side of caution (or perhaps even paranoia) in that those calls are not automatically a sign of a security breach - but some security breaches are easier to conduct if those calls are allowed.  For TPE, denying the ability to execute non-root non-self files is a defense against an insecure $PATH, which can affect any language.

----------

## mv

 *Hu wrote:*   

> denying the ability to execute non-root non-self files is a defense against an insecure $PATH

 

It is much more: It means that even if some intruder gets unlimited access as an untrusted user (and can modify that user's $PATH however he likes), he is not able to produce code which he can execute as a binary, thus making it much harder to obtain more privileges by some exploit.

Edit: Made the formulation clearer.

----------

## ago

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

----------

## olger901

What about the PaX patches? Will they remain available/free? Will they be added to the mainline of gentoo-sources?

----------

## jonathan183

I guess the masking of hardened-sources forces people to make a decision about what to do with the kernel.

Revert to gentoo-sources feels like a backwards step at the moment, staying on the stable 4.9 branch seems like a reasonable approach at the moment (using the patches ago posted about).

From the news item 2017-08-19 gentoo-sources and https://github.com/minipli/linux-unofficial_grsec look like the two obvious options to me. 

What are others doing ...

----------

## mx_

Some guy porting the patches seems like a bad idea to me.

What about using CentOS or SLES kernel sources and create an ebuild for those?

https://software.opensuse.org/package/kernel-source

https://git.centos.org/summary/?r=rpms/kernel.git

----------

## nokilli

 *jonathan183 wrote:*   

> I guess the masking of hardened-sources forces people to make a decision about what to do with the kernel.

 

Best possible outcome is that Linus now looks at the problem with new eyes, takes the enormous satisfaction he's due in making the kernel the beautiful beast it is with respect to performance and stability, and turns his undivided attention to security.

All he really needs to do is just make the proclamation.   Say that now is the time to move on security.  I truly believe this; he does that, this gets done.  So many people want to see this happen but he's, well, he's Linus... it's a hard road without his blessing.  And security was already an enormously frustrating problem.  Complicate it with politics?  There shouldn't be politics here.  There can't be.  My computer?  Then I get to decide what processes run and who gets to run them.  Period.

I'm just this guy with a laptop but I've been giving it lots of thought and there's all this stuff that you can do to make your system more secure but really it comes down to process: recognize that what you're doing is shit, own that, and then content yourself with today's incremental improvement.  And repeat.  What else can we do?

What puzzles me is, how is this any different than the problem Linux faced with respect to devices?  How many times were the way drivers work refactored in the kernel?  Some company comes out with a dumb product but people want to use it but wow the way it works is really retarded and we have to rewrite everything just so this idiocy can have it's own module... when does that process ever end?  Well, it's close to ending now.  I believe that the kernel today is very close to a state where every kind of idiocy on the part of device manufacturers has been dealt with in one form or the other and I don't understand why security can't be treated in the same way.  And yes I know about SoC's and that Linux is lagging here but like in every other aspect of life adversity here pays off over time.  The process is working.  We wouldn't be using Gentoo, using Linux, if it wasn't.

Maybe security is harder than that.  But doesn't that then mean we should be embracing its solution all the more?

Failing that, the outlook is fairly terrible.  Sitting from my very unprivileged position, it isn't entirely clear why security hasn't been given greater priority.  And living in a post-Snowden world, I do see the priority my government has placed on compromising the security of the systems I run and I'm forced to wonder how far their pursuit of total control has taken them.  Linus has hinted that he's had these kinds of conversations with the NSA-types.  We want to believe that the outcome of these conversations have been favorable to our interests, but we can't know that for sure, because we're actually living in a world where the government can order you to do something and then also order you to not reveal that fact.

There is a very frightening possibility that Linus has a gun to his head and is doing exactly what you or I would do in that situation.  Comply.

I remember back when SELinux was first introduced.  Maybe this will be controversial in this place but at the time my impression was that OpenBSD was the preferred OS if your priority was security.  So it was odd to see the NSA work to add mandatory access control to an OS that didn't then and doesn't now make security a priority.

The question I asked myself then was, how much of the NSA's budget was spent on working to protect the secrets of average ordinary Americans, and how much of it was spent to acquire the secrets of foreign nationals?  If I were to guess that this ratio was 1%, would that really be all that controversial?  So then what are the odds that SELinux was developed with our best interests first and foremost in mind?  Was it funded out of the 1% of the NSA budget allocated to protect our (Americans) secrets or the 99% spent to get into them?  Might this not have been a ploy to simply negate the momentum something like OpenBSD was enjoying at the time?  And looking at the mindshare enjoyed by OpenBSD and Linux today, is it fair to say that if this was the mission then that the mission has succeeded?

----------

## pjp

 *nokilli wrote:*   

> [All he really needs to do is just make the proclamation.   Say that now is the time to move on security.  I truly believe this; he does that, this gets done.  So many people want to see this happen but he's, well, he's Linus... it's a hard road without his blessing.  And security was already an enormously frustrating problem.

  Did not Linus have criticisms of Grsec code? Yet he let it in. While Linus' blessing may help, if a serious team got together to engineer a solution, past performance suggests Linux would allow it into the kernel. 

 *nokilli wrote:*   

> Complicate it with politics?  There shouldn't be politics here.

  Unfortunately, politics appear to be part of the human condition. Maybe we'll eventually evolve out of that.

 *nokilli wrote:*   

> Well, it's close to ending now.  I believe that the kernel today is very close to a state where every kind of idiocy on the part of device manufacturers has been dealt with in one form or the other and I don't understand why security can't be treated in the same way.

  Bolting security on as an afterthought is probably the wrong security-minded approach. Coming up with a secure design from scratch is probably a better end game. Then make Linux a legacy hardware compatibility layer. Anytime you buy crap from a crappy vendor, call the vendor out on it when their crap results in security problems. 

 *nokilli wrote:*   

> Maybe security is harder than that.  But doesn't that then mean we should be embracing its solution all the more?
> 
> Failing that, the outlook is fairly terrible.  Sitting from my very unprivileged position, it isn't entirely clear why security hasn't been given greater priority.

  Security isn't something everyone knows how to do well. Linus readily admits not being a great SA or in the past having had difficulty installing Debian. So it is quite reasonable to believe he isn't a security expert, and it may be a Good Thing that he's not the champion for security in Linux.

 *nokilli wrote:*   

> And living in a post-Snowden world, I do see the priority my government has placed on compromising the security of the systems I run and I'm forced to wonder how far their pursuit of total control has taken them.  Linus has hinted that he's had these kinds of conversations with the NSA-types.  We want to believe that the outcome of these conversations have been favorable to our interests, but we can't know that for sure, because we're actually living in a world where the government can order you to do something and then also order you to not reveal that fact.

  I don't for one second believe they have our interests on any list of priorities. Their list of priorities is the ability to bypass security in the pursuit of "National Security." I'll leave that as it is, otherwise it is likely to derail the thread, if it isn't already too late.

 *nokilli wrote:*   

> I remember back when SELinux was first introduced.  Maybe this will be controversial in this place but at the time my impression was that OpenBSD was the preferred OS if your priority was security.  So it was odd to see the NSA work to add mandatory access control to an OS that didn't then and doesn't now make security a priority.

  I think it primarily says that the NSA wanted to use Linux but recognized that it was inappropriate for their requirements. I also think it is likely for Linux to me more secure with SELinux than without. That may include protections from the NSA as well (though I'm skeptical).

 *nokilli wrote:*   

> Might this not have been a ploy to simply negate the momentum something like OpenBSD was enjoying at the time?  And looking at the mindshare enjoyed by OpenBSD and Linux today, is it fair to say that if this was the mission then that the mission has succeeded?

  The solution will be for people to stop chasing after the newest, shiniest development toys.

Given the recent history you've touched on, using if not migrating to OpenBSD is on my To Do list.

----------

## pjp

 *mx_ wrote:*   

> Some guy porting the patches seems like a bad idea to me.
> 
> What about using CentOS or SLES kernel sources and create an ebuild for those?
> 
> https://software.opensuse.org/package/kernel-source
> ...

  What do they offer to make them a compelling choice?

----------

## 188562

 *mx_ wrote:*   

> Some guy porting the patches seems like a bad idea to me.
> 
> What about using CentOS or SLES kernel sources and create an ebuild for those?
> 
> https://software.opensuse.org/package/kernel-source
> ...

 

there was one project sys-kernel/geek-sources::init_6 with USE="aufs bfq bld branding cjktty ck deblob exfat fedora gentoo grsec ice lqx mageia openelec openvz openwrt optimize pax pf reiser4 rh rsbac rt suse uek uksm zen zfs" I quit working on it because no one was interested in it.

----------

## mx_

 *pjp wrote:*   

>  *mx_ wrote:*   Some guy porting the patches seems like a bad idea to me.
> 
> What about using CentOS or SLES kernel sources and create an ebuild for those?
> 
> https://software.opensuse.org/package/kernel-source
> ...

 

Both companies pay developer teams to create a stable kernel with bugfixes, security patches and backports. They are also involved in kernel developing.

The kernels are validated for commercial server hardware and include security features like apparmor and selinux. At least the SLES12 kernel supports live patching and they ship live patches.

There is likely much more, I did not lookup a documentation yet.

And they won't shut down their work of course :-)

----------

## Ant P.

 *nokilli wrote:*   

> All he really needs to do is just make the proclamation.   Say that now is the time to move on security.  I truly believe this; he does that, this gets done.

 

If all it took was Linus reciting some magic words, the nvidia driver would be dead by now.

----------

## pjp

 *mx_ wrote:*   

> Both companies pay developer teams to create a stable kernel with bugfixes, security patches and backports. They are also involved in kernel developing.
> 
> The kernels are validated for commercial server hardware and include security features like apparmor and selinux. At least the SLES12 kernel supports live patching and they ship live patches.
> 
> There is likely much more, I did not lookup a documentation yet.
> ...

  Ah, thanks. I thought maybe there was some specific security alternative.

----------

## mx_

 *pjp wrote:*   

>  *mx_ wrote:*   Both companies pay developer teams to create a stable kernel with bugfixes, security patches and backports. They are also involved in kernel developing.
> 
> The kernels are validated for commercial server hardware and include security features like apparmor and selinux. At least the SLES12 kernel supports live patching and they ship live patches.
> 
> There is likely much more, I did not lookup a documentation yet.
> ...

 

That depends on your definition of "security".

I guess they don't apply the grsec patchset but they enable parts of PAX, include AppArmor and SELinux and have a business process of auditing and updating the code (https://en.opensuse.org/openSUSE:Security_Features). So yeah, they are a security alternative.

The gentoo-sources patchset for the longterm kernel looks mostly vanilla in comparison (https://dev.gentoo.org/~mpagano/genpatches/patches-4.9-51.htm) thus offering less security related patches. So I like the "borrowed enterprise kernel on gentoo" approach better.

----------

## pjp

@mx_

(and of course anyone else who may be interested)

openSUSE kernel sources 4.4.87-18.29.1

----------

## brendlefly62

I've been basically off the grid for about six months; just returned from a 2000+ mile hiking project.  I read the news today about sys-kernel/hardened-sources removal, oh boy:

 *Quote:*   

> ... we will be masking the hardened-sources on the 27th of August and will proceed to remove them from the tree by the end of September... Our recommendation is that users should consider using instead sys-kernel/gentoo-sources

 

Will Gentoo continue to support its line of "hardened" profiles?

I have several servers running on the hardened/linux/amd64 profile with kernels built from hardened-sources configured with grsec.  I also have a couple experimental desktops running on the hardened/linux/amd64 profile, with hardened-sources kernels not quite so hard as on servers (these have large package.use files to coordinate plasma, etc).  How should I plan to evolve these systems?

1. stay on the hardened profile and just switch to the gentoo-sources kernel?

2. switch to the default/linux/amd64 line of profiles? maybe the new 17.0?

3. is there an overlay already sourcing the work from https://github.com/copperhead/linux-hardened or https://github.com/minipli/linux-unofficial_grsec? could I use that in lieu of hardened-sources?

----------

## fedeliallalinea

See here

----------

## NeddySeagoon

brendlefly62,

In the /17.0/ series of profiles the hardened profile is going away.

You won't be asked to switch profiles until gcc-6 is stable. At that time, Position Independent Executatbles (-fPIE) vill became the default for everyone.

Its another rebuild lots of stuff as it breaks all the static libs on the system.

However, if you are coming from the hardened profile, you can skip the rebuild as USE=hardened gives you that already.

My understanding is that userspace won't change for hardened users - everyone else will need to get into line but the kernel hardened patch set will go away.

There are several places trying to keep the hardened patch set alive, either by bumping it from kernel to kernel or trying to merge bits and pieces upstream.

I've been running the default/linux/amd64/17.0/no-multilib/ profile for several months on my main desktop.  It mostly works but see the gcc-6.4 tracker bug.

If you can live with that try out the /17.0/ profile.  If not, wait for portage to tell you about the new profiles.

Where I need hardened, I've updated gcc ... mostly, but still use the hardened kernel and hardened profile.

I need to test the profile change from 13.0/hardened to /17.0/ in a KVM before I do it for real on a system I need.

----------

## pjp

Merged previous 3 posts.

----------

## Moonboots

NeddySeagoon

Sorry a little dense today !

If the hardened profile is going away in series 17.0 profile.  That will mean the "hardened" Flag will disappear and previously masked flags like JIT will return ?

----------

## NeddySeagoon

Moonboots,

Try the experiment for yourself. This is harmless as long as you do not install anynting whilu the /17.0/ profile is selected.

Run 

```
emerge --info
```

Select the the /17.0/ profile of your choice.  Its not in eselect profile yet, so make the symline by hand.

Run 

```
emerge --info 
```

again and compare the two outputs.

For per package USE changes run

```
emerge -pve @world
```

Switch back to your old profile before you forget.

----------

## zorry

 *NeddySeagoon wrote:*   

> Moonboots,
> 
> Try the experiment for yourself. This is harmless as long as you do not install anynting whilu the /17.0/ profile is selected.
> 
> Run 
> ...

 

Hardened have a sub profile under the 17.0 profile and will be added to more of the sub profiles.

----------

## depontius

 *zorry wrote:*   

> 
> 
> Hardened have a sub profile under the 17.0 profile and will be added to more of the sub profiles.

 

Is the "17.0" series going to subsume the "hardened" profile?  Currently we have "/usr/portage/profiles/hardened/linux/amd64" beside "/usr/portage/profiles/default/linux/amd64/13.0" and its children.  In the "17.0" series we also have "/usr/portage/profiles/default/linux/amd64/17.0/hardened".

----------

