| View previous topic :: View next topic |
| Author |
Message |
Uzytkownik
Guru
Joined: 31 Oct 2004
Posts: 399
Location: Bay Area, US
|
 Posted: Thu Apr 27, 2017 6:30 pm Post subject: hardened-sources going forward |
 |
|
Given that grsecurity stopped releasing patches post-4.9 what is the status of hardened-sources going forward?
_________________
I've probably left my head... somwhere. Please wait untill I find it. |
|
| Back to top |
|
 |
GSF1200S
n00b
Joined: 26 May 2010
Posts: 10
|
| Posted: Thu Apr 27, 2017 7:30 pm Post subject: Re: hardened-sources going forward |
|
|
| 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. |
|
| Back to top |
|
|
Uzytkownik
Guru
Joined: 31 Oct 2004
Posts: 399
Location: Bay Area, US
|
| Posted: Thu Apr 27, 2017 8:09 pm Post subject: Re: hardened-sources going forward |
|
|
| 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.
_________________
I've probably left my head... somwhere. Please wait untill I find it. |
|
| Back to top |
|
|
GSF1200S
n00b
Joined: 26 May 2010
Posts: 10
|
| Posted: Thu Apr 27, 2017 8:23 pm Post subject: Re: hardened-sources going forward |
|
|
| 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... |
|
| Back to top |
|
|
1clue
Advocate
Joined: 05 Feb 2006
Posts: 2569
|
|
| Back to top |
|
|
Jacekalex
Guru
Joined: 17 Sep 2009
Posts: 554
|
|
| Back to top |
|
|
nbrogan
n00b
Joined: 15 Apr 2017
Posts: 5
|
| Posted: Fri Apr 28, 2017 12:07 am Post subject: |
|
|
| 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. |
|
| Back to top |
|
|
1clue
Advocate
Joined: 05 Feb 2006
Posts: 2569
|
|
| Back to top |
|
|
Jacekalex
Guru
Joined: 17 Sep 2009
Posts: 554
|
| Posted: Fri Apr 28, 2017 12:13 am Post subject: |
|
|
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". |
|
| Back to top |
|
|
depontius
Advocate
Joined: 05 May 2004
Posts: 3522
|
| Posted: Fri Apr 28, 2017 12:16 am Post subject: |
|
|
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.
_________________
.sigs waste space and bandwidth |
|
| Back to top |
|
|
toralf
Developer
Joined: 01 Feb 2004
Posts: 3940
Location: Hamburg
|
| Posted: Fri Apr 28, 2017 7:50 am Post subject: |
|
|
| depontius wrote: | | As I look at its recommendations, I think I might like to consider that on my next kernel builds. |
+1 |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6780
|
| Posted: Fri Apr 28, 2017 7:58 am Post subject: |
|
|
| depontius wrote: | | KSPP [...] is better than a vanilla kernel |
Isn't it fully merged into vanilla kernel? |
|
| Back to top |
|
|
rip_her_APART
n00b
Joined: 27 Mar 2016
Posts: 3
|
| Posted: Fri Apr 28, 2017 10:26 pm Post subject: |
|
|
I feel so bad about this whole case. I don't know what to say or do  |
|
| Back to top |
|
|
Ant P.
Watchman
Joined: 18 Apr 2009
Posts: 6920
|
| Posted: Sat Apr 29, 2017 1:38 am Post subject: |
|
|
| 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. |
|
| Back to top |
|
|
Sadako
Advocate
Joined: 05 Aug 2004
Posts: 3792
Location: sleeping in the bathtub
|
| Posted: Sat Apr 29, 2017 3:23 am Post subject: |
|
|
| 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.
_________________
"You have to invite me in" |
|
| Back to top |
|
|
roki942
Apprentice
Joined: 18 Apr 2005
Posts: 285
Location: Seattle
|
| Posted: Sat Apr 29, 2017 3:42 am Post subject: |
|
|
Could the money trail on this actually lead beyond grsecurity?
That may be a very stupid question but I have an abundance of them.  |
|
| Back to top |
|
|
Ant P.
Watchman
Joined: 18 Apr 2009
Posts: 6920
|
| Posted: Sat Apr 29, 2017 8:54 pm Post subject: |
|
|
| 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. |
|
| Back to top |
|
|
rob_dot_p
n00b
Joined: 28 Jan 2017
Posts: 30
|
| Posted: Sat Apr 29, 2017 10:55 pm Post subject: |
|
|
| 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. |
|
| Back to top |
|
|
Nazzy
n00b
Joined: 26 May 2004
Posts: 34
|
| Posted: Sun Apr 30, 2017 11:12 pm Post subject: |
|
|
| 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. |
|
| Back to top |
|
|
depontius
Advocate
Joined: 05 May 2004
Posts: 3522
|
| Posted: Sun Apr 30, 2017 11:32 pm Post subject: |
|
|
| 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.
_________________
.sigs waste space and bandwidth |
|
| Back to top |
|
|
Ant P.
Watchman
Joined: 18 Apr 2009
Posts: 6920
|
| Posted: Mon May 01, 2017 7:06 pm Post subject: |
|
|
| 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.
|
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. |
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... |
|
| Back to top |
|
|
1clue
Advocate
Joined: 05 Feb 2006
Posts: 2569
|
| Posted: Mon May 01, 2017 7:42 pm Post subject: |
|
|
| 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.
|
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. |
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... |
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. |
|
| Back to top |
|
|
NTU
Apprentice
Joined: 17 Jul 2015
Posts: 187
|
| Posted: Tue May 02, 2017 1:33 am Post subject: |
|
|
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. |
|
| Back to top |
|
|
Hu
Administrator
Joined: 06 Mar 2007
Posts: 22680
|
| Posted: Tue May 02, 2017 1:54 am Post subject: |
|
|
| 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. |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6780
|
| Posted: Mon May 08, 2017 1:36 pm Post subject: |
|
|
| 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. |
|
| Back to top |
|
|
|
Networking & Security
