Skip to main content

Browse the archive

https://github.com/torvalds/linux
23 October 2021, 00:29:24 UTC
Revision 462e635e5b73ba9a4c03913b77138cd57ce4b050 authored by Tavis Ormandy on 09 December 2010, 14:29:42 UTC, committed by Linus Torvalds on 15 December 2010, 20:30:36 UTC 
install_special_mapping skips security_file_mmap check.
 
The install_special_mapping routine (used, for example, to setup the
vdso) skips the security check before insert_vm_struct, allowing a local
attacker to bypass the mmap_min_addr security restriction by limiting
the available pages for special mappings.

bprm_mm_init() also skips the check, and although I don't think this can
be used to bypass any restrictions, I don't see any reason not to have
the security check.

  $ uname -m
  x86_64
  $ cat /proc/sys/vm/mmap_min_addr
  65536
  $ cat install_special_mapping.s
  section .bss
      resb BSS_SIZE
  section .text
      global _start
      _start:
          mov     eax, __NR_pause
          int     0x80
  $ nasm -D__NR_pause=29 -DBSS_SIZE=0xfffed000 -f elf -o install_special_mapping.o install_special_mapping.s
  $ ld -m elf_i386 -Ttext=0x10000 -Tbss=0x11000 -o install_special_mapping install_special_mapping.o
  $ ./install_special_mapping &
  [1] 14303
  $ cat /proc/14303/maps
  0000f000-00010000 r-xp 00000000 00:00 0                                  [vdso]
  00010000-00011000 r-xp 00001000 00:19 2453665                            /home/taviso/install_special_mapping
  00011000-ffffe000 rwxp 00000000 00:00 0                                  [stack]

It's worth noting that Red Hat are shipping with mmap_min_addr set to
4096.

Signed-off-by: Tavis Ormandy <taviso@google.com>
Acked-by: Kees Cook <kees@ubuntu.com>
Acked-by: Robert Swiecki <swiecki@google.com>
[ Changed to not drop the error code - akpm ]
Reviewed-by: James Morris <jmorris@namei.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
1 parent 0fcdcfb
Raw File
Tip revision: 462e635e5b73ba9a4c03913b77138cd57ce4b050 authored by Tavis Ormandy on 09 December 2010, 14:29:42 UTC
install_special_mapping skips security_file_mmap check.
Tip revision: 462e635
devices.txt 
Device Whitelist Controller

1. Description:

Implement a cgroup to track and enforce open and mknod restrictions
on device files.  A device cgroup associates a device access
whitelist with each cgroup.  A whitelist entry has 4 fields.
'type' is a (all), c (char), or b (block).  'all' means it applies
to all types and all major and minor numbers.  Major and minor are
either an integer or * for all.  Access is a composition of r
(read), w (write), and m (mknod).

The root device cgroup starts with rwm to 'all'.  A child device
cgroup gets a copy of the parent.  Administrators can then remove
devices from the whitelist or add new entries.  A child cgroup can
never receive a device access which is denied by its parent.  However
when a device access is removed from a parent it will not also be
removed from the child(ren).

2. User Interface

An entry is added using devices.allow, and removed using
devices.deny.  For instance

	echo 'c 1:3 mr' > /cgroups/1/devices.allow

allows cgroup 1 to read and mknod the device usually known as
/dev/null.  Doing

	echo a > /cgroups/1/devices.deny

will remove the default 'a *:* rwm' entry. Doing

	echo a > /cgroups/1/devices.allow

will add the 'a *:* rwm' entry to the whitelist.

3. Security

Any task can move itself between cgroups.  This clearly won't
suffice, but we can decide the best way to adequately restrict
movement as people get some experience with this.  We may just want
to require CAP_SYS_ADMIN, which at least is a separate bit from
CAP_MKNOD.  We may want to just refuse moving to a cgroup which
isn't a descendant of the current one.  Or we may want to use
CAP_MAC_ADMIN, since we really are trying to lock down root.

CAP_SYS_ADMIN is needed to modify the whitelist or move another
task to a new cgroup.  (Again we'll probably want to change that).

A cgroup may not be granted more permissions than the cgroup's
parent has.
back to top