On Wed, Aug 02, 2006 at 02:15:39PM -0400, Jeff Dike wrote:
> On Wed, Aug 02, 2006 at 10:35:20AM -0700, Jim Carter wrote:
> > untrustedProg cannot use legitimate means to induce UML1's kernel to map
> > kernel memory (except according to the UNIX file permissions of /dev/kmem).
>
> And whether /de
On Wed, Aug 02, 2006 at 10:35:20AM -0700, Jim Carter wrote:
> untrustedProg cannot use legitimate means to induce UML1's kernel to map
> kernel memory (except according to the UNIX file permissions of /dev/kmem).
And whether /dev/kmem allows writing. This has been controversial in
the past (and
On Tue, 1 Aug 2006, TongKe Xue wrote:
> Original Belief: I can use UML as a virtual machine; jail untrusted
> processes.
>
> Let's say I am a user U, on a machine M running Linux.
> I run an instance, UML1 of User Mode Linux.
> Within this instance of UML1, I create a new user "jailedUser".
> "j
On Tue, Aug 01, 2006 at 12:51:44AM -0700, 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?
The process can't form a UML ker
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« do
Please enlighten me of my ignorance.
Original Belief: I can use UML as a virtual machine; jail untrusted
processes.
Problem:
Let's say I am a user U, on a machine M running Linux.
I run an instance, UML1 of User Mode Linux.
Within this instance of UML1, I create a new user "jailedUser".
"jai
