[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: DEFAULT_MMAP_MIN_ADDR change breaks ssh on arm

On Wed, Mar 19, 2008 at 12:06 PM, maximilian attems <max@stro.at> 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 and
above, and above, and above, and all 2.6.25
versions [1], 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
        default 0
	  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
	  /proc/sys/vm/mmap_min_addr tunable.


[1] http://kerneltrap.org/Linux/Patching_CVE-2008-0600_Local_Root_Exploit

Gordon Farquharson
GnuPG Key ID: 32D6D676

Reply to: