Virtual Machines and Memory Protections [LWN.net]

Virtual Machines and Memory Protections

Posted Nov 24, 2006 2:05 UTC (Fri) by bluefoxicy (guest, #25366)
In reply to: Virtual Machines and Memory Protections by davecb
Parent article: Virtual Machines and Memory Protections

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)

(Log in to post comments)

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.