How to know if grsec isn't breaking anything?

Utini · 2016-02-21 19:58:48

Hey there,

I am using Arch for ~8months so far and I believe I have everything set up correctly and with all the stuff that is needed (e.g. thermald which is unknown, not even in the official repo but a very important package altough it isn't working on all systems bug free so far, also not on mine but the bugs are being fixed right now).
I know the struggle of not knowing what is breaking smth or not knowing if something isn't just installed and running but also working correctly or not (e.g. thermald). So I wonder:

If I run grsec with paxd, how do I know and monitor that grsec + paxd aren't breaking things?

For example, I know grsec breaks NVIDIA for me (unless I install grsec patched kernel from the AUR which I don't want to). I know grsec broke iceweasel/Firefox for me.
But I only know that because I actively use those packages and fail to start them. But for a package/service that just sits in the backround and is supposed to do stuff silently and maybe only daily/weekly/monthly, I probably wouldn't ever notice that they aren't working correctly (e.g. thermald, tlp, SSD trim, dnscache, dnscrypt, etc etc).

Thanks !

Last edited by Utini (2016-02-21 20:01:35)

Awebb · 2016-02-21 22:35:57

No word about a custom kernel to get nvidia running. From the wiki:

the nvidia-grsecAUR package in the AUR patches the proprietary NVIDIA driver for compatibility with the CONFIG_PAX_USERCOPY and CONFIG_PAX_CONSTIFY_PLUGIN features

Short answer: You don't.

If you have anything mission critical, then you should test it against the grsec kernel before deploying it to work in the background. The real questions are: Why do you use the grsec kernel? Do you understand, what it does and what it does differently from the vanilla kernel? Are you able to identify issues caused by the patched kernel versus issues caused by whatever you did wrong elsewhere? Are you able to come up with an attack, that would be able to put the kernel modifications to the test? How do you know it makes an actual difference?

Utini · 2016-02-21 22:57:45

Awebb wrote:

No word about a custom kernel to get nvidia running. From the wiki:
the nvidia-grsecAUR package in the AUR patches the proprietary NVIDIA driver for compatibility with the CONFIG_PAX_USERCOPY and CONFIG_PAX_CONSTIFY_PLUGIN features
Short answer: You don't.
If you have anything mission critical, then you should test it against the grsec kernel before deploying it to work in the background. The real questions are: Why do you use the grsec kernel? Do you understand, what it does and what it does differently from the vanilla kernel? Are you able to identify issues caused by the patched kernel versus issues caused by whatever you did wrong elsewhere? Are you able to come up with an attack, that would be able to put the kernel modifications to the test? How do you know it makes an actual difference?

Oh thanks, I didnt understand the nvidia-grsecAUR then. Thanks for telling me this. Maybe this is a decent option for me now

Well yes, but once it is in the backround: What if a future update "silently breaks" it?

I use the grsec kernel for improved security against exploits and other things.
Yes I believe I understand what grsec is compared to vanilla.
I know that it makes a difference by following security threads and how to protect against them (which grsec does in 90%).
I am not sure if I can identify issues cause by the pached kernel. I guess this is why I made this thread

Awebb · 2016-02-22 08:05:36

If you have mission critical software, you need to re-validate that software after each update of the grsec kernel. There is no way around this. You can test everything manually or make a list of functions your programs use and check them against the patch log of grsec. There is a good reason, why grsecurity's patch set is not by default part of the kernel. It is not meant to be used in passing, but as a major part of a security setup. I'm not sure how to tell you this, but your question itself indicates, that you don't actually know, what the changes do in detail. Until you do, a manual re-validation of your system is necessary.

bstaletic · 2016-02-22 09:06:59

I, just like Awebb assumes for the OP, am not entirely sure what the patches do. Though everything just worked, I couldn't complete V8 engine compiling process with the error being "Killed". Dmesg revealed the grsec is killing it when it does something grsec doesn't allow. As I had no idea how to work around this I just recompiled my kernel without the grsec patches.

Arch Linux

#1 2016-02-21 19:58:48

How to know if grsec isn't breaking anything?

#2 2016-02-21 22:35:57

Re: How to know if grsec isn't breaking anything?

#3 2016-02-21 22:57:45

Re: How to know if grsec isn't breaking anything?

#4 2016-02-22 08:05:36

Re: How to know if grsec isn't breaking anything?

#5 2016-02-22 09:06:59

Re: How to know if grsec isn't breaking anything?

Board footer