grsecurity forums

Hi,

I've just started experimenting with grsecurity and am trying to load it on my Gentoo laptop. What PAX options can I safely enable and still use XFree?

Thanks,

meekrob

meekrob wrote:Hi,

I've just started experimenting with grsecurity and am trying to load it on my Gentoo laptop. What PAX options can I safely enable and still use XFree?

the feature that interferes with a typical XFree86 server is the non-executable pages enforcement (both PAGEEXEC and SEGMEXEC), so they'd be the ones to be careful about when you enable them in the kernel config (which is recommended of course since that's one of the core features of PaX). there are two solutions for XFree86:

1. use 'chpax -sp' on the server binary to disable non-exec pages on it (or the ACL system).

2. compile a statically linked server and still have the non-exec protection on XFree86 as well.

the preferable solution is 2 of course and since you're using a source based distro, this should be easy enough for you to do. the trick to get a statically linked XFree86 server is very easy: before compiling/configuring it you have to add the following line to xc/config/cf/host.def :

Code: Select all

#define DoLoadableServer NO

note that gentoo may already define other things in there, so don't blindly overwrite this file. also if gentoo defines BeforeVendorCF/AfterVendorCF sections in host.def then the above line should go into the AfterVendorCF part. furthermore you can recompile the server as an ET_DYN executable to take advantage of full randomization (details are both on the PaX and the grsecurity sites). finally, here's a little table that will tell you how much memory is consumed (process RSS) using various feature combinations (numbers are in MB and taken just after startup):

Code: Select all

ET_EXEC/dynamic/nothing:7.5
ET_EXEC/static/nothing: 6.5
ET_EXEC/static/SEGMEXEC:8.2
ET_DYN/static/nothing: 12
ET_DYN/static/SEGMEXEC:19.5

a few notes on this table:
1. the PAGEEXEC memory usage would be the same as the 'nothing' case, so i've omitted those cases (because of the large RSS i don't recommend using PAGEEXEC on XFree86).
2. this compilation used the default host.def file + that one line addition, so all default XFree86 features were enabled (and contributed to the binary size and memory usage).
3. the ET_DYN server was not compiled with -fPIC, so text relocations had to be applied dramatically increasing RSS. using -fPIC would have saved on the initial relocations a lot as the .text section is some 7 MB large itself, most of which is never used during runtime (and hence would not contribute to RSS).

So my config can look like this:

Code: Select all

[*] Enforce non-executable pages                                                         
[*] Paging based non-executable pages (NEW)
[*] Segmentation based non-executable pages (NEW)
[*]    Emulate trampolines (NEW)
[ ]     Automatically emulate sigreturn trampolines (NEW)                                                 
[*]    Restrict mprotect() (NEW)
[*]     Disallow ELF text relocations (DANGEROUS) (NEW)
[*] Address Space Layout Randomization
[*]   Randomize kernel stack base (NEW)
[*]   Randomize user stack base (NEW)                                                             
[*]   Randomize mmap() base (NEW)
[*]   Randomize ET_EXEC base (NEW)                                                                       
[*] Deny writing to /dev/kmem, /dev/mem, and /dev/port
[ ] Disable privileged I/O
[*] Remove addresses from /proc/pid/maps     

and I can use chpax or acls to adjust for performance and usability? Then I can save the recompiling for the future.

Thanks for your time,

meekrob

meekrob wrote:and I can use chpax or acls to adjust for performance and usability? Then I can save the recompiling for the future.

yes, this will work, however be careful with the ELF text relocations stuff, make sure you know what you're doing (check out the mailing list, i posted a mail not long time ago on how to determine when one's system is ready for this feature).

PaX Team wrote:

meekrob wrote:Hi,

I've just started experimenting with grsecurity and am trying to load it on my Gentoo laptop. What PAX options can I safely enable and still use XFree?

the feature that interferes with a typical XFree86 server is the non-executable pages enforcement (both PAGEEXEC and SEGMEXEC), so they'd be the ones to be careful about when you enable them in the kernel config (which is recommended of course since that's one of the core features of PaX). there are two solutions for XFree86:

1. use 'chpax -sp' on the server binary to disable non-exec pages on it (or the ACL system).

2. compile a statically linked server and still have the non-exec protection on XFree86 as well.

the preferable solution is 2 of course and since you're using a source based distro, this should be easy enough for you to do. the trick to get a statically linked XFree86 server is very easy: before compiling/configuring it you have to add the following line to xc/config/cf/host.def :

Code: Select all

#define DoLoadableServer NO

note that gentoo may already define other things in there, so don't blindly overwrite this file. also if gentoo defines BeforeVendorCF/AfterVendorCF sections in host.def then the above line should go into the AfterVendorCF part. furthermore you can recompile the server as an ET_DYN executable to take advantage of full randomization (details are both on the PaX and the grsecurity sites). finally, here's a little table that will tell you how much memory is consumed (process RSS) using various feature combinations (numbers are in MB and taken just after startup):

Code: Select all

ET_EXEC/dynamic/nothing:7.5
ET_EXEC/static/nothing: 6.5
ET_EXEC/static/SEGMEXEC:8.2
ET_DYN/static/nothing: 12
ET_DYN/static/SEGMEXEC:19.5

a few notes on this table:
1. the PAGEEXEC memory usage would be the same as the 'nothing' case, so i've omitted those cases (because of the large RSS i don't recommend using PAGEEXEC on XFree86).
2. this compilation used the default host.def file + that one line addition, so all default XFree86 features were enabled (and contributed to the binary size and memory usage).
3. the ET_DYN server was not compiled with -fPIC, so text relocations had to be applied dramatically increasing RSS. using -fPIC would have saved on the initial relocations a lot as the .text section is some 7 MB large itself, most of which is never used during runtime (and hence would not contribute to RSS).

I have mandrake 9.2 with xfree86 allready running.
What can i do to get xfree running with chpax?

netpython wrote:I have mandrake 9.2 with xfree86 allready running.
What can i do to get xfree running with chpax?

i don't understand you, if you have xfree running already, what do you need to change with chpax on it?

PaX Team wrote:

netpython wrote:I have mandrake 9.2 with xfree86 allready running.
What can i do to get xfree running with chpax?

i don't understand you, if you have xfree running already, what do you need to change with chpax on it?

Sry , you're right, i meant actually , i have mandrake 9.2
with both the latest "normal" and "secure" kernels running.
I found out by recompiling the "secure"-kernel that it's patched with grsecurity,mandrake ships both kernel with their 9.2 boxes.

I saw that in a thread on this page that there are 2 ways
of enabling the use of xfree86 when runnning a grsecurity patched kernel (1) use the chpax utillity (prob not safe)
(2) statically linked xfree86 server (correct me if i'm wrong ) (Quote:compile a statically linked server and still have the non-exec protection on XFree86 as well)

My goal is: to enable the most grsecurity options avaible and while still being able to run xfree86( i like online gaming with linux :}) , option 2 seems to be most appropiate , how can i get a statically linked xfree86 server on mandrake 9.2 ??

netpython wrote:My goal is: to enable the most grsecurity options avaible and while still being able to run xfree86( i like online gaming with linux :}) , option 2 seems to be most appropiate , how can i get a statically linked xfree86 server on mandrake 9.2 ??

i don't know anything about how one recompiles/changes packages on mandrake, you should probably ask that on their forums/lists. as for getting X run with most protections enabled, there's a few things that could be done beyond/instead of using the static server:

1. instead of using elfloader you can use dlloader, that is, X modules would become normal .so shared libraries and X would load them via dlopen() which does not conflict with PaX. there are a few folks working out the details, you should contact or at least follow the Adamantix and Hardened Gentoo projects where these changes will appear. if you or someone else wants to do it the hard (manual) way, let me know and i'll post the details.

2. you can compile the X server as a special executable (ET_DYN or as it's called lately, PIE) so that it will be fully randomized. this is easiest to do when you have a special gcc that produces PIEs by default, both of the above mentioned projects have their way to do it automatically. furthermore the latest version of propolice can compile X now as well (i have no data on its performance impact though).

3. you can have an X server and modules that require not text relocations, but that needs a few patches here and there, you should talk to the Hardened Gentoo guys where they're being accumulated.

4. even with all the above X is one of the most risky applications (in terms of what a successful attack can gain), in particular it needs (or more precisely, requests and gets) unrestricted access to both the I/O port space and physical memory. this level of access is enough to circumvent any kind of kernel based protection mechanism so obviously it should be better controlled (and more fine-grained than what grsecurity allows now). this is on my/our todo list, albeit not with the highest priority.

The hard way mostly works better and lasts longer.
I would like to give it a try,great opportunity to gain
some more knowledge.So if you could post the details that
would be very nice.