Re: DEFAULT_MMAP_MIN_ADDR change breaks ssh on arm
On Wed, Mar 19, 2008 at 12:06 PM, maximilian attems <firstname.lastname@example.org> wrote:
> [ adding relevant cc peoples to your message, no more insight ]
> On Wed, Mar 19, 2008 at 06:46:37PM +0100, Martin Michlmayr wrote:
> > The following change
> > r10769 | maks | 2008-03-10 17:03:03 +0100 (Mon, 10 Mar 2008) | 8 lines
> > security: set DEFAULT_MMAP_MIN_ADDR to 65536
> > Low address space to protect from user allocation, see
> > a5ecbcb8c13ea8a822d243bf782d0dc9525b4f84, runtime tunable on
> > /proc/sys/vm/mmap_min_addr. let's see if we get any fallout.
> > double checked after Kconfig recommendation that fedora uses
> > that recommendation too.
> > breaks ssh on arm. While root can still log in via ssh, normal users
> > cannot. ssh almost manages to log in but when it comes to starting a
> > shell the connection simply closes. Changing DEFAULT_MMAP_MIN_ADDR
> > back to 0 fixes this.
> > maks, should I simply set DEFAULT_MMAP_MIN_ADDR to 0 on ARM or should
> > I report this to the SE Linux folks or someone else? I've no idea how
> > SE Linux works, so any help is welcome.
On the GLAN Tank, values larger than 32768 cause ssh to fail, whereas
32768 and lower allow ssh to work. However, it appears that the
exploit (CVE-2008-0600) is fixed in kernel versions 22.214.171.124 and
above, 126.96.36.199 and above, 188.8.131.52 and above, and all 2.6.25
versions , so why can't we set DEFAULT_MMAP_MIN_ADDR to 0 for all
Alternatively, would it help to enable SELinux for ARM? This idea is
based on the help in security/Kconfig:
int "Low address space to protect from user allocation"
depends on SECURITY
This is the portion of low virtual memory which should be protected
from userspace allocation. Keeping a user from writing to low pages
can help reduce the impact of kernel NULL pointer bugs.
For most users with lots of address space a value of 65536 is
reasonable and should cause no problems. Programs which use vm86
functionality would either need additional permissions from either
the LSM or the capabilities module or have this protection disabled.
This value can be changed after boot using the
GnuPG Key ID: 32D6D676