[prev in list] [next in list] [prev in thread] [next in thread] 

List:       user-mode-linux-user
Subject:    Re: [uml-user] Security of Non-Root User Accounts in UML Instance
From:       BlaisorBlade <blaisorblade_spam () yahoo ! it>
Date:       2004-08-27 15:33:37
Message-ID: 200408271733.37530.blaisorblade_spam () yahoo ! it
[Download RAW message or body]

Alle 04:28, mercoledì 28 luglio 2004, Sean O'Dell ha scritto:
> On Tuesday 27 July 2004 18:07, Ali Campbell wrote:
> > I found the previous post about rooting UMLs and the effect this has on
> > the host. One of BlaisorBlade's.
> >
> > http://sourceforge.net/mailarchive/message.php?msg_id=8872905
> >
> > Seems I was almost right, but not quite - inserting a kernel module into
> > the UML to execute nasty code is apparently fairly easy. It was
> > corrupting the kernel using /dev/mem and /dev/kmem that was a bit harder.
>
> That was very illuminating, thank you.
>
> So, here's my personal take on the issue: Linux still provides the same
> amount of protection preventing regular users from obtaining root, whether
> in UML or not.  Users who obtain root inside UML could probably work out a
> way to get access in the host as the user.
>
> So, if I ever give anyone root access inside UML, I should consider UML not
> as much of a security layer as a convenience layer, and assume that if they
> have root in UML, they have user-level access in the host.
>
> Basically, I assume a root user in UML can gain access in the host as the
> user UML was run under.
>
> Which is fine.  I already give people user-level access in the host, but I
> chroot everyone away from everyone else.  It sounds like I can give their
> chroot area even fewer support files (just enough to run UML), making that
> level of security even safer, and they'll still end up with far more
> functionality because they'll have a full working UML instance to play in.
>
> That all seems reasonable to me.

> 	Sean O'Dell

By the way, if you remove module support in the UML kernel, it becomes much 
more difficult to have user-level access on the host, since it's hard to 
insert modules; and if you make /dev/kmem not-writable in the kernel, it 
becomes almost impossible (except for any particular bug which could be 
discovered in UML).

To make /dev/kmem not writable, you can either remove CAP_SYS_RAWIO from every 
process, or apply the attached patch, which makes /dev/kmem and /dev/mem not 
writable.

-- 
Paolo Giarrusso, aka Blaisorblade
Linux registered user n. 292729

["kmem-not-write.patch" (text/x-diff)]

Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade_spam@yahoo.it>
---

 vanilla-linux-2.6.8.1-paolo/drivers/char/mem.c |    2 ++
 1 files changed, 2 insertions(+)

diff -puN drivers/char/mem.c~kmem-not-write drivers/char/mem.c
--- vanilla-linux-2.6.8.1/drivers/char/mem.c~kmem-not-write	2004-08-27 17:29:04.391042584 +0200
+++ vanilla-linux-2.6.8.1-paolo/drivers/char/mem.c	2004-08-27 17:31:39.025534568 +0200
@@ -187,6 +187,7 @@ static ssize_t write_mem(struct file * f
 			 size_t count, loff_t *ppos)
 {
 	unsigned long p = *ppos;
+	return -EINVAL;
 
 	if (!valid_phys_addr_range(p, &count))
 		return -EFAULT;
@@ -297,6 +298,7 @@ static ssize_t write_kmem(struct file * 
 	ssize_t written;
 	char * kbuf; /* k-addr because vwrite() takes vmlist_lock rwlock */
 
+	return -EINVAL;
 	if (p < (unsigned long) high_memory) {
 
 		wrote = count;
_

-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click
_______________________________________________
User-mode-linux-user mailing list
User-mode-linux-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-user

[prev in list] [next in list] [prev in thread] [next in thread]