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

[Kevin F. Quinn]

On 6/10/2005 15:09:58, Dan Hollis (reg5423374856 at anime.net) wrote:
> On Thu, 6 Oct 2005, Kevin F. Quinn wrote:
> > 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.
> 
> afaik this has never been the case. not only has the format changed in 
> the past, you can't even rely on /proc existing at all.
> 
> dl_iterate_phdr is the only 'reliable' method i know of. it also provides 
> somewhat more verbose data on mappings than /proc/(pid|self)/maps 
> does.

Hmm; as far as I can tell, dl_iterate_phdr doesn't detail all the maps, it
just returns Elf program header data.  So it's missing the stack base and
size in particular (which is the reason why glibc and boehm-gc are parsing
/proc/self/{maps|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?
> 
> Well it does seem silly to restrict reading maps|stat from itself, since 
> you can get the same info via other methods anyway.
> 
> that is to say, if you're using /proc/(self|pid)/maps, you're doing 
> things the hard way.
> 
> -Dan