TongKe Xue wrote: > Now, we know that M is running in ring 0. > UML1 is running as a process, so it's in ring 3. > > If this is the case, what protects "untrustedProg" from playing around > with the kernel memory of UML1?
If you're running UML in SKAS mode (as you should), then »untrustedProg« does not have direct access to UML1's kernel memory. The situation is similar to running two different (unrelated) processes (A and B) on the same (physical) machine; process A does not have access to process B's memory although they are both running in ring 3. > If not, this means that "untrustedProg" effectively has the same > privileges as UML1, which would be having the same priviledges as U on M, > ... in which case I'm no longer sure what I gain by running UML in the > first place. »untrustedProg« could exploit a local vulnerability to gain »root« access in UML1. However this translates, at best, to U's privileges on M. Exploiting another local hole on M to gain »root« on M is vastly more difficult from a process running within UML than it is from a process running on M directly. Perfect security is impossible (given finite resources). However, jailing a program in UML does raise the bar somewhat. Anselm (This is my personal opinion and not that of Linup Front GmbH.) -- Anselm Lingnau ... Linup Front GmbH ... Linux-, Open-Source- & Netz-Schulungen Linup Front GmbH, Postfach 100121, 64201 Darmstadt, Germany [EMAIL PROTECTED], +49(0)6151-9067-103, Fax -299, www.linupfront.de ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ User-mode-linux-user mailing list User-mode-linux-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-user
