I develop the Linux+ELF side of UPX, which compresses executable programs
to save storage space and invocation time. Immediately after kernel
execve() of a compressed program, a small decompressor reconstructs
the original PT_LOADs directly into address space; then execution proceeds
as usual. The decompression writes instructions which execute later,
directly into pages with both PROT_WRITE and PROT_EXEC, so perhaps
there should be a { denied } avc due to execmem when SELinux is in
enforcing mode. Reading the explanation of execmem in
http://people.redhat.com/drepper/selinux-mem.html
supports this theory.
However, under all released FC5 kernels including 2.6.16-1.2096_FC5,
I see no execmem complaints. Strace of typical execution begins:
-----
old_mmap(0xc06000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0xc06000) = 0xc06000
/* interval [0xc06000, +4096) is written and executed >now< */
old_mmap(0x8048000, 45056, PROT_NONE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x8048000
old_mmap(0x8048000, 40647, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x8048000
/* interval [0x8048000, +40644) is written >now< */
mprotect(0x8048000, 40644, PROT_READ|PROT_EXEC) = 0
/* interval [0x8048000, +40644) is executed later */
old_mmap(0x8052000, 3800, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0xa000) = 0x8052000
-----
Notice that the first and third old_mmap() specify (PROT_WRITE | PROT_EXEC)
with (MAP_FIXED | MAP_ANONYMOUS) [and other bits, too.] SELinux was is
targeted enforcing mode, and this was an unconfined compressed executable.
How did these system calls evade being denied due to execmem?
--
--
fedora-selinux-list mailing list
fedora-selinux-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
