mmap_min_addr/SECURITY_DEFAULT_MMAP_MIN_ADDR suggested values

mmap_min_addr/SECURITY_DEFAULT_MMAP_MIN_ADDR suggested values

[Dr. David Alan Gilbert]

Hi,
  The config help for SECURITY_DEFAULT_MMAP_MIN_ADDR suggests 65536
as a 'reasonable' value for x86 and the original mmap_min_addr
patches suggested that 'something like 64k' was a safe value that
wouldn't affect most programs.

  Where does this 64k value come from?  A number of distros seem
to have followed this advice and have it set to 64k; but is there
really any likely benefit of having it larger than PAGE_SIZE say?

I ask because I have an ancient program that maps stuff at 8k; the
general advice of stuff on the net seems to be to set this limit
to 0 if people have problems (I'm just lowering it to 4k),
but I was thinking perhaps using a lower default value would be more
secure since less people would take the easy answer and just turn the
feature off altogether.

Dave

-- 
 -----Open up your eyes, open up your mind, open up your code -------   
/ Dr. David Alan Gilbert    | Running GNU/Linux on Alpha,68K| Happy  \ 
\ gro.gilbert @ treblig.org | MIPS,x86,ARM,SPARC,PPC & HPPA | In Hex /
 \ _________________________|_____ http://www.treblig.org   |_______/

Re: mmap_min_addr/SECURITY_DEFAULT_MMAP_MIN_ADDR suggested values

[Arjan van de Ven]

On Mon, 23 Jun 2008 14:53:37 +0100
"Dr. David Alan Gilbert" <linux@treblig.org> wrote:

> Hi,
>   The config help for SECURITY_DEFAULT_MMAP_MIN_ADDR suggests 65536
> as a 'reasonable' value for x86 and the original mmap_min_addr
> patches suggested that 'something like 64k' was a safe value that
> wouldn't affect most programs.
> 
>   Where does this 64k value come from?  A number of distros seem
> to have followed this advice and have it set to 64k; but is there
> really any likely benefit of having it larger than PAGE_SIZE say?

there's a few things in the kernel that are bigger than 4K (or rather,
lead to pointers beyond 4K) so it's not all that bad advice.

> 
> I ask because I have an ancient program that maps stuff at 8k; the
> general advice of stuff on the net seems to be to set this limit
> to 0 if people have problems (I'm just lowering it to 4k),
> but I was thinking perhaps using a lower default value would be more
> secure since less people would take the easy answer and just turn the
> feature off altogether.

interesting... what does the program do?
(applications making assumptions on where they can mmap stuff... that's
not really valid. Realistically, the only safe way to use MAP_FIXED is
on memory that you got from mmap before.. think about it: what if
glibc happened to mmap something there first?)

So I'm quite curious what/why this app is doing this


-- 
If you want to reach me at my work email, use arjan@linux.intel.com
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org

Re: mmap_min_addr/SECURITY_DEFAULT_MMAP_MIN_ADDR suggested values

[Dr. David Alan Gilbert]

* Arjan van de Ven (arjan@infradead.org) wrote:
> On Mon, 23 Jun 2008 14:53:37 +0100
> "Dr. David Alan Gilbert" <linux@treblig.org> wrote:
> 
> > Hi,
> >   The config help for SECURITY_DEFAULT_MMAP_MIN_ADDR suggests 65536
> > as a 'reasonable' value for x86 and the original mmap_min_addr
> > patches suggested that 'something like 64k' was a safe value that
> > wouldn't affect most programs.
> > 
> >   Where does this 64k value come from?  A number of distros seem
> > to have followed this advice and have it set to 64k; but is there
> > really any likely benefit of having it larger than PAGE_SIZE say?
> 
> there's a few things in the kernel that are bigger than 4K (or rather,
> lead to pointers beyond 4K) so it's not all that bad advice.

Hmm OK.

> > I ask because I have an ancient program that maps stuff at 8k; the
> > general advice of stuff on the net seems to be to set this limit
> > to 0 if people have problems (I'm just lowering it to 4k),
> > but I was thinking perhaps using a lower default value would be more
> > secure since less people would take the easy answer and just turn the
> > feature off altogether.
> 
> interesting... what does the program do?

It's an emulator mapping an ancient binary at it's original load address.

> (applications making assumptions on where they can mmap stuff... that's
> not really valid. Realistically, the only safe way to use MAP_FIXED is
> on memory that you got from mmap before.. think about it: what if
> glibc happened to mmap something there first?)

If you don't have address space randomisation and break randomisation
(both of which you can turn off by personality flags) then the 
allocation of VM is actually quite predictable; if you get your
application loaded fairly high up in memory then most stuff ends up
being allocated after that leaving a nice clear area below it.
(It's a pity that there is no way of setting address space randomisation
and break randomisation from ELF flags - it would be a lot easier than
having to ensure something already turned them off before you are run).

In general there are a few apps that really like to control what there
VM layout looks like; I realise they are a bit on the odd side but it
would be nice to leave room for those apps to do that.

(I realise you can do the same with the minimum mmap thing but only
with SELinux (which quite a lot of people still don't use) or by
granting CAP_SYS_RAWIO - which seems like a very odd choice of CAP.)

Dave
-- 
 -----Open up your eyes, open up your mind, open up your code -------   
/ Dr. David Alan Gilbert    | Running GNU/Linux on Alpha,68K| Happy  \ 
\ gro.gilbert @ treblig.org | MIPS,x86,ARM,SPARC,PPC & HPPA | In Hex /
 \ _________________________|_____ http://www.treblig.org   |_______/