Adam Thornton wrote: >Well, one thing I can see exploiting under VM would be an agressive use >of DCSSes (or something like them--I don't know if you can put DCSSes in >other data spaces, and I don't think you can execute code from data >spaces, but you see where this is going), so you could share your shared >libraries between Linux images. If each one were in its own read-only >address space, you'd get a vast reduction in overall memory footprint, >plus code couldn't exploit bugs in the standard libraries--even if you >have a buffer overflow (or whatever) vulnerability, a) the code is off >in its own private address space, so you can't go trash anything else, >and b) your virtual machine has that segment marked read-only anyway.
Using DCSSes to reduce overall memory footprint is certainly a useful goal, which we are actually working on right now. As to security implications, however, DCSSes contribute exactly nothing IMO. Whether to use separate address spaces or not has nothing whatsoever to do with whether you put into those separate address spaces, once you've got them, a mapping of a DCSS or just a mapping of regular memory. (However, changing the Linux tool chain and basically *all* applications from a flat address space to multiple address spaces is an *enormous* task; and I'm not convinced this buys you anything w.r.t. security that can't be achieved much more easily, e.g. by StackGuard-type compilers. Certainly nobody has even attempted to do this w.r.t. segments on Intel for example -- at least as far as I know.) Also, shared libraries always have a read-only part (code and read-only data) and a read-write part (variables); the read-only part is mapped read-only by default, without any DCSSes in sight. (Sure, you *can* change that using mprotect or so, but once the exploit code has gained enough control to issue system calls, everything that is to be lost is already lost ...) Likewise, the read-write part would need to be mapped from regular memory even when using DCSSes. In general, I can only re-iterate my belief that attempting to guarantee security *even in the presence of bugs* is ultimately futile. Bye, Ulrich -- Dr. Ulrich Weigand [EMAIL PROTECTED]
