Re: [uml-user] UML is a security Risk?

[BlaisorBlade <bla...@ya...>]

Alle 12:11, gioved=EC 1 luglio 2004, Erik de Bruijn ha scritto:
> I believe the interface to the host is pretty safe. But there may be an
> issue here: Loading kernel modules in an UML (GUEST) would run them in the
> UM-kernel's layer. But wouldn't it possible for tricking the executable
> kernel to run it on the host?
Well, the UM-kernel layer actually runs on the host, and so your module.
> The loadable kernel modules is still a bit
> vague to me, concerning UML kernels (I'm not a kernel-hacker yet... so
> maybe the question is dumb)

No, the question is not dumb. Well, this is a situation:

=2D suppose that a cracker intrudes your UML and becomes root inside it. Ca=
n it=20
hurt at the host? Yes, it can insmod a module and then this module, like th=
e=20
UML kernel, runs on the host. So you must assume, when planning your=20
security, that if a cracker is root on your UML he can have local access (n=
ot=20
as root) on the host.

I.e., like you already said, good host OS security is essential.

Well, a script-kiddie cannot do this (nobody wrote a such module), but it's=
=20
not too hard to write the code. Most seriously, we have not yet started=20
seeing, on the Uml mailing lists, bugfix for potential security bugs; which=
=20
means that there is a lot of ones.

=2Dsuppose you build a kernel without module support (this reasoning applie=
s=20
both to host and guest kernel); can you trust no module being insmoded? NO!=
=20
There is still the /dev/kmem - /dev/mem port. Look on the net, it's a well=
=20
known problem with well known fixes. However, I think that while for i386=20
Phrack explained how to do this, the procedure changes a bit for UML, and t=
he=20
changes means that probably only an expert programmer can insmod through=20
/dev/kmem inside UML.

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