User-mode Linux kernel port

On Monday 26 July 2004 16:29, Sean O'Dell wrote:
> I've read a number of things talking about the security of UML, but I don't
> know that I completely understand everything, so I have a question:
>
> If I have a UML instance in which I give a third party a non-root user
> account, how secure is that UML instance?  I don't know if there's a danger
> the user may hack out to the real machine as root, with a user ID of
> themselves, the user ID the UML instances runs under, all or none of the
> above.
>
> Can anyone provide some enlightenment?

No one has any idea about the security of a non-root-user inside a UML 
instance?

	Sean O'Dell

There are a lot of variables that come into play.
For ultimate security, this is what you need to do.
Run all uml guest OSes under a user account. (Preferably a different user
for each guest os).
Keep everything that a uml instance needs under one directory tree so you
can chroot the process before you start the guest kernel.
Make sure you have the skas mode patch applied to the host OS. (This
protects the guest kernel from being hacked. In tt mode, it is VERY trivial
to make the kernel crash, since it is running in unprotected user space.
Skas fixes that problem, and gives you a speed increase. Alternatively you
can use the "jail" argument to the guest kernel in tt mode, but the docs say
there is a performance hit.)
At that point, you can give complete root access to the uml guest to a third
party any not have to worry about it. If they where to manage to somehow
make the uml kernel crash, AND execute some arbitrary code on the host
system, they'd still be a plain user account in a chrooted environment, and
could only break their own uml even more by overwriting the files that make
their uml work. So...there you go. As for non-root access, I'd still go with
the above recommendations, just because getting root access on a box that
you already have a valid user account for is less difficult that you would
think. All you need to do is find some bug just about anywhere in one of the
many setuid root programs in any default linux install and exploit it to get
root access. The simple rule to system administration is: don't give user
access to anyone you don't trust to not try to get root access. If you have
even a small idea that they might someday try something funny, you shouldn't
give them a user account. A valid user account with a working shell is
almost always the first step to gaining root access.

----- Original Message ----- 
From: "Sean O'Dell" <sean@...>
To: <user-mode-linux-user@...>
Sent: Tuesday, July 27, 2004 3:05 PM
Subject: Re: [uml-user] Security of Non-Root User Accounts in UML Instance


> On Monday 26 July 2004 16:29, Sean O'Dell wrote:
> > I've read a number of things talking about the security of UML, but I
don't
> > know that I completely understand everything, so I have a question:
> >
> > If I have a UML instance in which I give a third party a non-root user
> > account, how secure is that UML instance?  I don't know if there's a
danger
> > the user may hack out to the real machine as root, with a user ID of
> > themselves, the user ID the UML instances runs under, all or none of the
> > above.
> >
> > Can anyone provide some enlightenment?
>
> No one has any idea about the security of a non-root-user inside a UML
> instance?
>
> Sean O'Dell
>
>
> -------------------------------------------------------
> 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=4721&alloc_id=10040&op=click
> _______________________________________________
> User-mode-linux-user mailing list
> User-mode-linux-user@...
> https://lists.sourceforge.net/lists/listinfo/user-mode-linux-user
>

On Tuesday 27 July 2004 12:45, Eric Shorkey wrote:
> There are a lot of variables that come into play.
> For ultimate security, this is what you need to do.
> Run all uml guest OSes under a user account. (Preferably a different user
> for each guest os).
> Keep everything that a uml instance needs under one directory tree so you
> can chroot the process before you start the guest kernel.
> Make sure you have the skas mode patch applied to the host OS. (This
> protects the guest kernel from being hacked. In tt mode, it is VERY trivial
> to make the kernel crash, since it is running in unprotected user space.
> Skas fixes that problem, and gives you a speed increase. Alternatively you
> can use the "jail" argument to the guest kernel in tt mode, but the docs
> say there is a performance hit.)
> At that point, you can give complete root access to the uml guest to a
> third party any not have to worry about it. If they where to manage to
> somehow make the uml kernel crash, AND execute some arbitrary code on the
> host system, they'd still be a plain user account in a chrooted
> environment, and could only break their own uml even more by overwriting
> the files that make their uml work. So...there you go. As for non-root
> access, I'd still go with the above recommendations, just because getting
> root access on a box that you already have a valid user account for is less
> difficult that you would think. All you need to do is find some bug just
> about anywhere in one of the many setuid root programs in any default linux
> install and exploit it to get root access. The simple rule to system
> administration is: don't give user access to anyone you don't trust to not
> try to get root access. If you have even a small idea that they might
> someday try something funny, you shouldn't give them a user account. A
> valid user account with a working shell is almost always the first step to
> gaining root access.

It's nice to hear a current reprise of this information.  Even though I've 
read a lot of this elsewhere, I can never tell what's old and what's new.  
Thank you.

However, rather than simply playing it safe and assuming non-root-users are as 
likely to gain root access to the host system as a root user is, I would like 
to know if there are any specific differences between a root user and 
non-root-user as it pertains to security inside a UML instance.

I don't implicitly "trust" any of my users, or I'd give them root access from 
the get-go.  I have a certain amount of "distrust" in them, and I would like 
to know a little more about the security problems I face with non-root-users 
inside a UML instance.

Maybe some better questions:

Does UML offer non-root-users any more of an opportunity to gain root access 
to the host system than non-root-users already in the host system, or is it 
actually it harder to gain root access to the host system?

I understand there are ways to bork the host kernel and gain root access, and 
that skas alleviates a lot of that risk.  But non-root-users...do they have 
the same opportunities to gain root access to the host as a root user does 
inside the UML instance, or less opportunities?

	Sean O'Dell

There was a post by (I believe) Jeff Dike, or possibly Blaisorblade, 
about some of this, not so long ago.

> Does UML offer non-root-users any more of an opportunity to gain root access 
> to the host system than non-root-users already in the host system, or is it 
> actually it harder to gain root access to the host system?

A non-root guest (UML) user has more work to do to root your host 
machine than a non-root host user does. Perhaps it's best to look at 
three scenarios:

i) Unprivileged user on host machine : needs to break 1 layer of security
------------------------------------
A user having an unprivileged account on a normal Linux machine needs to 
breach one layer of security only to root it. He will need (generally) 
to either find a setuid program with a flaw such that it can be coerced 
into executing code of his choice, or alternatively a bug in a Linux 
syscall or similar which allows the same thing (kernel bug, like the 
do_brk vuln that was knocking about not so long ago). Either way it 
amounts to being able to convince the CPU to run something of the user's 
choice when it's running in kernel mode, as opposed to user mode.

ii) Root user on guest (UML) instance : needs to break 2 or 3 layers of 
security
-------------------------------------
Depending on the setup, root on a UML may have to breach two or three 
layers of security to root the host box.

a) - find a way to break out of the UML to execute arbitrary commands on 
the host as the host user account under which the UML runs (an 
unprivileged host user);
b) - break the host chroot jail applied to this host user (if present);
c) - root the host box via a kernel / setuid app vulnerability, as in (i).

(b) and (c) are in the realm of non-UML security, so I won't go into 
them. It was postulated recently on this list that (a) could be achieved 
by inserting a rogue kernel module into the UML kernel in memory, from 
inside the UML. This effectively allows execution of arbitrary code on 
the host machine with the permissions of the user under which the UML 
instance is running. It was however also mentioned that this trick would 
require a custom built kernel module and good knowledge of kernel 
hacking, and would likely be beyond the capability of your average 
script kiddie. My knowledge of the innards of the kernel falls into the 
"tourist" category, so I can neither confirm nor deny this from my own 
knowledge.

iii) Non-root UML user on guest (UML) instance : needs to break 3 or 4 
layers of security
----------------------------------------------
In this case, the unprivileged UML user must:
a) root the UML, through a syscall or setuid vulnerability in either the 
UML kernel or a program inside the UML filesystem;
b) find a way to break out of the UML to execute arbitrary code as an 
unprivileged user on the host, perhaps by inserting a rogue UML kernel 
module;
c) break the chroot jail applied to this unprivileged user on the host 
(if present);
d) root the host using a kernel bug or setuid application bug.

Hope this helps.

Ali

On Tuesday 27 July 2004 14:14, Ali Campbell wrote:
>
> iii) Non-root UML user on guest (UML) instance : needs to break 3 or 4
> layers of security
> ----------------------------------------------
> In this case, the unprivileged UML user must:
> a) root the UML, through a syscall or setuid vulnerability in either the
> UML kernel or a program inside the UML filesystem;

Okay, this is the bit of information I guess I was after.  So, a user would 
have to gain root access inside the UML first, and then cascade to root the 
same way a root user would from there.

So, that means that a non-root-user and a root user don't have the same 
opportunities to break out of a UML instance; the user has to become root 
inside UML or there is no way to gain root in the host.

I don't completely understand how UML works exactly, so it's hard for me to 
understand, truly, what the security issues are.  What I was afraid of was 
that UML somehow "hooks" into the host kernel as root, and that UML would 
somehow provide users in a UML instance unique opportunities to gain root 
access to the host through that "hook."  I thought that perhaps if that was 
the case, that opportunity might be available to all users in a UML instance, 
not just the root user.

But if there are no such opportunities, and users must somehow get root in a 
UML instance first, then that's good news.  Having non-root-users in UML 
means there's yet another level of security there.

Thank you for that explanation!

	Sean O'Dell

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.

Ali

Basically, what you said is true. UML runs in userspace on the host, which
means that any sort of breakage that occurs in the UML guest can't get
directly into the host kernel space. If you're smart, you'll run the UML
guest process under an unprivileged user account, so even breaking the UML
guest won't directly get you root on the host. All in all, it's about as
secure as you're going to get without simply unplugging the network cable
from the back and surrounding the host with 8 feet of concrete. ;)


----- Original Message ----- 
From: "Sean O'Dell" <sean@...>
To: <user-mode-linux-user@...>
Sent: Tuesday, July 27, 2004 6:11 PM
Subject: Re: [uml-user] Security of Non-Root User Accounts in UML Instance


> On Tuesday 27 July 2004 14:14, Ali Campbell wrote:
> >
> > iii) Non-root UML user on guest (UML) instance : needs to break 3 or 4
> > layers of security
> > ----------------------------------------------
> > In this case, the unprivileged UML user must:
> > a) root the UML, through a syscall or setuid vulnerability in either the
> > UML kernel or a program inside the UML filesystem;
>
> Okay, this is the bit of information I guess I was after.  So, a user
would
> have to gain root access inside the UML first, and then cascade to root
the
> same way a root user would from there.
>
> So, that means that a non-root-user and a root user don't have the same
> opportunities to break out of a UML instance; the user has to become root
> inside UML or there is no way to gain root in the host.
>
> I don't completely understand how UML works exactly, so it's hard for me
to
> understand, truly, what the security issues are.  What I was afraid of was
> that UML somehow "hooks" into the host kernel as root, and that UML would
> somehow provide users in a UML instance unique opportunities to gain root
> access to the host through that "hook."  I thought that perhaps if that
was
> the case, that opportunity might be available to all users in a UML
instance,
> not just the root user.
>
> But if there are no such opportunities, and users must somehow get root in
a
> UML instance first, then that's good news.  Having non-root-users in UML
> means there's yet another level of security there.
>
> Thank you for that explanation!
>
> Sean O'Dell
>
>
> -------------------------------------------------------
> 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=4721&alloc_id=10040&op=click
> _______________________________________________
> User-mode-linux-user mailing list
> User-mode-linux-user@...
> https://lists.sourceforge.net/lists/listinfo/user-mode-linux-user
>

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

Alle 04:28, mercoled=EC 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=3D8872905
> >
> > 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 harde=
r.
>
> 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 n=
ot
> as much of a security layer as a convenience layer, and assume that if th=
ey
> 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=
=20
more difficult to have user-level access on the host, since it's hard to=20
insert modules; and if you make /dev/kmem not-writable in the kernel, it=20
becomes almost impossible (except for any particular bug which could be=20
discovered in UML).

To make /dev/kmem not writable, you can either remove CAP_SYS_RAWIO from ev=
ery=20
process, or apply the attached patch, which makes /dev/kmem and /dev/mem no=
t=20
writable.

=2D-=20
Paolo Giarrusso, aka Blaisorblade
Linux registered user n. 292729