[grsec] Restrictions on /proc/<pid>/[maps|stat] - relax for /proc/self?

Kevin F. Quinn ml at kevquinn.com
Thu Oct 6 14:48:34 EDT 2005


Hi.

While messing around, I've tripped over the restriction on visiblity of
/proc/self/maps and /proc/self/stat, in support of PaX' ASLR.  A few things
use these to retrieve the stack base and size.

For example, in glibc's libpthread, pthread_attr_getstack() returns sensible
results for child threads' stack base and size (the stack area for these is
all generated locally in the library or the calling applicaion so is no
secret to the application).  However it fails for the main thread, which
on glibc is obtained by reading /proc/self/maps and picking the block that
contains __libc_stack_end.

An example that uses /proc/self/stat is the boehm-gc garbage-collection
library.  This one's interesting as on systems that don't provide
/proc/self/stat it will scan addresses until it gets a memory fault to
find the stack base.

Generally speaking, the data in /proc/self/maps and /proc/self/stat isn't
secret as such; an application knows where its code, data and stack are
including the location of code in shared libraries.  However it's just
easier and more reliable to grab the relevant information from
/proc/self/maps and /proc/self/stat.

To the point, then.  I was wondering if it would be sensible to relax the
grsecurity restriction on /proc/<pid>/[maps|stat] where the task reading
the data is <pid>.  Thoughts?



More information about the grsecurity mailing list