Virtual Machines and Memory Protections [LWN.net]

Virtual Machines and Memory Protections

Posted Nov 23, 2006 19:20 UTC (Thu) by bluefoxicy (guest, #25366)
In reply to: Virtual Machines and Memory Protections by davecb
Parent article: Virtual Machines and Memory Protections

> When it's actually calling mmap or mprotect, the process context is present, and the kernel can see if it actually has the permission before it makes the change

Consider that the kernel doesn't know who called mmap() or mprotect() though. mmap() goes into mmap@@GLIBC, which goes into syscall@@GLIBC, which enters the kernel at the syscall entry point plus the offset for mmap(). Same with mprotect().

The kernel isn't tracking code call paths (this is difficult, would be very slow, and can be spoofed); it's the entire process that's allowed to do it. If you say the JIT is allowed to call mprotect(PROT_WRITE|PROT_EXECUTE), and the JIT links with libxml2, then a bug in libxml2 will allow an attacker to mprotect(PROT_WRITE|PROT_EXECUTE) ONLY in the JIT process and not in any other program using libxml2.

I'm trying to think of a way to contextually control calls, but right now there's no mechanism and nothing I can prove secure. I will think about it.

(Log in to post comments)

Virtual Machines and Memory Protections

Posted Nov 24, 2006 1:16 UTC (Fri) by davecb (subscriber, #1574) [Link]

Goodness gracious! That would make it extremely difficult to
do any decison dependant on who's making the system call, which
depends on having a process context.

Are you sure that's the case in Linux? Unix from v6 onwards
certainly knows
who's calling and what permissions they have. The whole
trusted computing base work (from which fine-grained permissions
come) is completely dependant on that, and SE Linux certainly
has the user's permissions, category and security level...

I can't imagine how normal Linux might avoid that.

--dave

Virtual Machines and Memory Protections

Posted Nov 24, 2006 2:05 UTC (Fri) by bluefoxicy (guest, #25366) [Link]

You have a PROCESS context; however, a process.. let's say /bin/cat.. has libraries it uses. Any code in those libraries is running in that process' context. So if mysql uses libc6, then libc6 code is run with mysql's privileges; while if eye of gnome uses libc6, libc6 code is being executed with the user's privileges.

Look at Exec Shield even. Libraries like libgcrypt11 are marked needing an executable stack; this causes half of GNOME as well as Gaim and Firefox to have an executable stack because they use libgcrypt11. Once this was fixed in Ubuntu, a large number of programs suddenly didn't have an executable stack anymore. It's not like the stack is only executable when libgcrypt11 tries to execute it; if libpng tries to execute code on the stack and normally fails, it'll succeed just because libgcrypt11 is linked to the application.

Short version: Unix/POSIX/Linux can only distinguish between PROCESSES, not CODE. (limitation of the CPU in many, many cases)

fine-grained permissions

Posted Nov 28, 2006 2:22 UTC (Tue) by xoddam (subscriber, #2322) [Link]

I think you've missed the point about fine-grained permissions.
Presumably the JIT compiler only needs to set write+execute on a VM area
once, at startup. Once it has done that, the entire process can drop the
privilege that allows it to do so.

This does not mean that it's impossible for an exploit of a system
library to write and call into that wx VM area once it exists, but
risk-mitigation techniques like address randomisation are just as valid
for JIT object code as they are for mapped .so files.

The point stands that any system that includes 'eval' is vulnerable to
this class of attack, no matter how it is implemented.