is only grsecurity enought, or -fstack-protector required ?

[amax]

hello, ppl!

Should I use only all grsecurity features at HIGH level with libsafe
and NOT recompile all my libs/binaries

or

maybe, initially, should I recompile my current gentoo installation with
new flag

USE="pic pie hardened static erandom"

and only afer that use kernel with grsec enabled ?

P.S. I am not planning to use selinux or rsbac or lsm at all.

[siti]

Recompiling with both -fstack-protector and PIC/PIE helps add alot of security. So I would reccomend you do that!

[PaX Team]

maybe, initially, should I recompile my current gentoo installation with new flag

USE="pic pie hardened static erandom"

and only afer that use kernel with grsec enabled ?

gentoo has a hardened subproject and profile that does its best to create a safe userland, take a look at that.

[torne]

You shouldn't enable pic/pie/hardened yourself if you can avoid it; instead, you should use the hardened profile (change the /etc/make.profile symlink) and recompile gcc and binutils, then the entire world (emerge gcc binutils && emerge glibc && emerge -e world). That will do all the pic/pie/hardened behaviour for you. You probably don't want USE=static because that will compile *many* packages statically, including quite a few that you will use often; having that many copies of libc around will severly bloat your memory usage. Apply USE=static on a per-package basis for things like X that have problems dynamically loading modules.

The hardened profile enables -fstack-protector too. You don't need to change your USE flags (and definately do not change CFLAGS/LDFLAGS - the PIC/PIE options are added to the GCC specfile and shouldn't be specified there) other than to add erandom, if you want it.

[NeoMike]

From my extensive experimentation and now running a dozen+ systems with Grsec/PAX , Hardened Gentoo (pic/pie/hardened), and Libsafe... this is what I have learned:

As stated in a previous message; Enabling pic/pie/hardened does require that you rebuild gcc, binutils, and glibc before anything will be built hardened. To do it right, see the previous message.

pic/pie are really handy (required) for building ET_DYN executables that PAX can randomize with minimal loss of performance vs building ET_EXEC and forcing randomization. This really isnt a huge deal, but when you really harden your system you can lose a lot of performance. This is a safe/secure way to get a little back... atleast when programs start. emerge pax-utils to see what's linked as ET_DYN or ET_EXEC.

USE="hardened" and CFLAGS with -O -O2 -O3 -O4+ are almost mutually exclusive. The Propolice/SSP protections are significantly less effective with these compile options. -Os does produce slower binaries, but does allow SSP to stop a much larger number of exploit attempts. In the documentation, somewhere, it does mention that -O2 and -03 do make it less effective, but through some testing even -O had made a huge difference.

(note: if people are interested, I would can publish results and document my testing methods ... Otherwise I am too lazy)

Do *NOT* build LibSafe with -fomit-frame-pointer. Binaries that preload LibSafe are okay to be built without a frame pointer, but LibSafe really does require its frame pointer to work.

Although I used to build almost all my binaries staticly as well, it does negate all LibSafe protections. You should also be aware of:
A) "static" should only be used on specific packages, putting it in /etc/make.conf can and will break something when you least expect it.
B) If a library/dependancy has a vulnerability, you need to rebuild the dependancy and everything that links to it.
C) It uses it more space. Not a big deal these days, but everything helps.

As a side note... none of these protections will stop an application vulnerability. Make sure you configure your apps well otherwise all this work was for nothing.

I have also done some testing to see what Propolice/SSP, LibSafe and PAX catch and in what percentages. If people are truly interested, I'll publish.

Thanks for listening to me rant.

Mike

[PaX Team]

pic/pie are really handy (required) for building ET_DYN executables that PAX can randomize with minimal loss of performance vs building ET_EXEC and forcing randomization. This really isnt a huge deal, but when you really harden your system you can lose a lot of performance.

can you quantify this?

[NeoMike]

Wow, good question.

Yes.

That a good enough answer? (joke)

Which part would you like me to quantify? There are several statements.

You got me, I don't know it all. I admit, I did get some of my information from posts on here. I may not post much, but I do read. I did specify where I did test, but this is one area where I have not extensively tested, and should have specified.

To break it down:

pic/pie are really handy (required) for building ET_DYN executables that PAX can randomize with minimal loss of performance vs. building ET_EXEC and forcing randomization.

A) the gentoo USE flags pic/pie are required to build proper ET_DYN executables under gentoo. This isnt under debate, I assume.
B) I read on previous messages on the original grsecurity forum about ET_DYN allowing the execution of processed with randomized memory to occur faster. This is based upon information that I read, so it may not be correct or interpreted correctly.

This really isn’t a huge deal, but when you really harden your system you can lose a lot of performance.

Most of the time, hardening reduces the amount of overhead on the system by reducing unneeded crud. (i.e. - disabling and moving stuff you don’t need, both on the system and in applications) This is a good thing.

When you start getting overly paranoid, like me, hardening can work against you – atleast performance wise.

This is how:

A) By default, Propolice/SSP ads about 0-8% performance hit, depending on the application. (see http://www.research.ibm.com/trl/project ... 0000000000 )

I mentioned this in my previous message, so I won’t go in to detail, but I found through testing that GCC compile options directly affected the functionality of Propolice/SSP. –Os would allow Propolice/SSP to catch the most overflow attempts, while –O3 would catch the least. (none, -O and –O2 would fall in the middle). By my memory, -O3 would render propolice/ssp almost completely ineffective, and –Os was almost 15-20% more effective than –O2. Meaning if you wanted the extra assurance, you would use –Os, which would optimize all binaries for size and not speed… Making your binaries even slower, but harder to overflow.

B) Libsafe can have, as they put it, less than 15% overhead on commonly used applications. ( http://www.research.avayalabs.com/proje ... aton_tests ) Using libsafe on programs can and will slow it down, the real measure can only be done on each program, as their use of ANSI-C string functions will be different.

C) If you really harden your system, you probably (at least you should be) enforcing that only stronger encryption/authentication methods that can be used in applications, disallowing breaches of privacy through downgrade attacks, brute force attacks, etc. Although this isnt perfect (is anything?), it’s a nice little layer. Still to my point, enforcing stronger encryption/authentication can add more processing, thus slowing your system a little more.

D) More related to PAX, using randomization vs. static memory layout causes more processing to be performed when a process starts and allocates memory. Although I do not have hard number on this, it doesn't take a rocket scientist to realize that it is doing more work initially. As to ET_DYN being faster than ET_EXEC on starting processes, I do not have hard numbers. Only read it here previously, and possibly mis-interpreted.

E) The more extensive access control lists you have (iptables, tcpwrappers, posix ACL’s, grsecurity, etc/whatever) the more performance impact they will have. Okay so you can optimize the lists so they have minimal impact, but they still have a direct impact on performance.

And there are probably even more factors.

The more insane your hardening, the worse you can make performance. All the little additions you make here and there can add up. Its not really a knock against any specific hardening tools, such as grsec or anything else.

No I do not have hard numbers on this, would you like some? Come up with a specific test and I’ll run it, but many of the tests would be subjective to configuration.

Of course, there is something to be said for simplicity.

So, is my logic completely flawed? Please educate me. (Sometimes the best way to learn is to be proven wrong)

[PaX Team]

Wow, good question.

Yes.

That a good enough answer? (joke)

Which part would you like me to quantify? There are several statements.

actually, i was meaning to highlight the lose lots of performance part, guess i should quote more selectively .

B) I read on previous messages on the original grsecurity forum about ET_DYN allowing the execution of processed with randomized memory to occur faster. This is based upon information that I read, so it may not be correct or interpreted correctly.

what would be the original forum if not this one? other than that, i can't imagine anyone making this claim given that the exact opposite has to be true: ET_DYN executables need runtime relocation whereas ET_EXEC ones don't.

A) By default, Propolice/SSP ads about 0-8% performance hit, depending on the application. (see http://www.research.ibm.com/trl/project ... 0000000000 )

i know all that, i was wondering if you had numbers yourself.

I mentioned this in my previous message, so I won’t go in to detail, but I found through testing that GCC compile options directly affected the functionality of Propolice/SSP. –Os would allow Propolice/SSP to catch the most overflow attempts, while –O3 would catch the least. (none, -O and –O2 would fall in the middle). By my memory, -O3 would render propolice/ssp almost completely ineffective, and –Os was almost 15-20% more effective than –O2. Meaning if you wanted the extra assurance, you would use –Os, which would optimize all binaries for size and not speed… Making your binaries even slower, but harder to overflow.

where does this 15-20% come from? i mean, what kind of tests were these? also, i heard that -O3 behaviour should be better since last June or so, but i haven't verified it myself, maybe you could.

B) Libsafe can have, as they put it, less than 15% overhead on commonly used applications.

hmm, what's the point of using libsafe when you already have ssp? libsafe detects the same linear stack overflow exploits that ssp, just at a different phase.

D) More related to PAX, using randomization vs. static memory layout causes more processing to be performed when a process starts and allocates memory. Although I do not have hard number on this, it doesn't take a rocket scientist to realize that it is doing more work initially.

hmm, this is a 'yes and no' thing. mapping a file at a random location doesn't cost inherently more except for getting the entropy for the random base address, that's something you probably cannot measure because it's so small compared to the whole of process image creation (the execve() syscall). there's one measurable source of slowdown in PaX (not related to randomization), which is vma mirroring used in SEGMEXEC, that effectively doubles the number of executable mappings and that shows up on execve() and fork() microbenchmarks (e.g., lmbench).

No I do not have hard numbers on this, would you like some? Come up with a specific test and I’ll run it, but many of the tests would be subjective to configuration.

well, i was sort of hoping that your extensive experimentation has already produced results that you alluded to, you could start with publishing those. personally, i was only interested in seeing the 'lots of performance' bits, for now i don't see where that would come from (or at least how grsec/ssp play a role in it).

[NeoMike]

Without making a super long reply again (not very good at writing, if you didn't notice)

A) Sorry, like I said in my last message, I did no real testing for performance.

B) my "extensive testing" was in 2 tests. How compile options affected propolice, and what propolice, libsafe, and pax would catch. I never did do a formal writeup, but was prompted to do the testing after running across propolice documentation that stated -O3 would break it.

Test 1 was conducted on a non-grsecurity kernel machine. I wrote a perl script to compile a set of test exploits using different permutations of common compile options. The base findings were that only -O options changed its effectiveness. As of march, when I did the test, -O3 all but broke propolice. -Os consistantly caught more overflow attempts.

Test 2 I remember less results for, sorry. That being said, LibSafe did catch a few things that ProPolice did not. LibSafe and Propolice do not function excally the same. From my testing in march, libsafe did catch a few things that propolice did not. libsafe even catches a few things that PAX does not seem to catch in paxtest. I don't have the propolice results handy, but just an example of the paxtext results with and without libsafe, below, are enough to convince me to run libsafe.

If you would seriously like to the results, I can and will re-run the tests and document the results. Give me 2 weeks, under my current project load, this is enough time. I did not document it last time, because only 1 person showed any interest.

Anyway, the paxtest results.

Without Libsafe

Code: Select all

Return to function (strcpy)              : Vulnerable
Return to function (strcpy, RANDEXEC)    : Vulnerable
Return to function (memcpy)              : Vulnerable
Return to function (memcpy, RANDEXEC)    : Vulnerable

With libsafe:

Code: Select all

Return to function (strcpy)              : Libsafe version 2.0.16
Detected an attempt to write across stack boundary.
Terminating /usr/lib/paxtest/rettofunc1.
    uid=0  euid=0  pid=15472
Call stack:
Killed
Return to function (strcpy, RANDEXEC)    : Libsafe version 2.0.16
Detected an attempt to write across stack boundary.
Terminating /usr/lib/paxtest/rettofunc1x.
    uid=0  euid=0  pid=12997
Call stack:
Killed
Return to function (memcpy)              : Libsafe version 2.0.16
Detected an attempt to write across stack boundary.
Terminating /usr/lib/paxtest/rettofunc2.
    uid=0  euid=0  pid=12328
Call stack:
Killed
Return to function (memcpy, RANDEXEC)    : Libsafe version 2.0.16
Detected an attempt to write across stack boundary.
Terminating /usr/lib/paxtest/rettofunc2x.
    uid=0  euid=0  pid=25443
Call stack:
Killed


These results were generated with the following kernel options:

Code: Select all

# PaX Control
# CONFIG_GRKERNSEC_PAX_SOFTMODE is not set
CONFIG_GRKERNSEC_PAX_EI_PAX=y
CONFIG_GRKERNSEC_PAX_PT_PAX_FLAGS=y
CONFIG_GRKERNSEC_PAX_NO_ACL_FLAGS=y
# CONFIG_GRKERNSEC_PAX_HAVE_ACL_FLAGS is not set
# CONFIG_GRKERNSEC_PAX_HOOK_ACL_FLAGS is not set
CONFIG_GRKERNSEC_PAX_NOEXEC=y
CONFIG_GRKERNSEC_PAX_PAGEEXEC=y
CONFIG_GRKERNSEC_PAX_SEGMEXEC=y
# CONFIG_GRKERNSEC_PAX_EMUTRAMP is not set
CONFIG_GRKERNSEC_PAX_MPROTECT=y
# CONFIG_GRKERNSEC_PAX_NOELFRELOCS is not set
CONFIG_GRKERNSEC_PAX_ASLR=y
CONFIG_GRKERNSEC_PAX_RANDKSTACK=y
CONFIG_GRKERNSEC_PAX_RANDUSTACK=y
CONFIG_GRKERNSEC_PAX_RANDMMAP=y
CONFIG_GRKERNSEC_PAX_RANDEXEC=y

Anyway, talk to you guys later.

[PaX Team]

Test 2 I remember less results for, sorry. That being said, LibSafe did catch a few things that ProPolice did not. LibSafe and Propolice do not function excally the same. From my testing in march, libsafe did catch a few things that propolice did not.

do you remember what these tests were?

libsafe even catches a few things that PAX does not seem to catch in paxtest. I don't have the propolice results handy, but just an example of the paxtext results with and without libsafe, below, are enough to convince me to run libsafe.

Anyway, the paxtest results.

Without Libsafe

Code: Select all

Return to function (strcpy)              : Vulnerable
Return to function (strcpy, RANDEXEC)    : Vulnerable
Return to function (memcpy)              : Vulnerable
Return to function (memcpy, RANDEXEC)    : Vulnerable

the above tests are meant to fail under PaX (well, the RANDEXEC ones should have been caught since you had RANDEXEC in your kernel, but that's another bughunt), even if you have ssp enabled by default (the makefile explicitly disables ssp). recompile those tests with ssp and they all will be caught since they're all simple linear stack overflows. of course if you're running 3rd party binary-only applications where ssp is not an option, libsafe can still be useful.