Virtual Machines and Memory Protections [LWN.net]

Virtual Machines and Memory Protections

Posted Nov 24, 2006 1:16 UTC (Fri) by davecb (subscriber, #1574)
In reply to: Virtual Machines and Memory Protections by bluefoxicy
Parent article: Virtual Machines and Memory Protections

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

(Log in to post comments)

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.