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=
hurt at the host? Yes, it can insmod a module and then this module, like th=
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=
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=
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=
means that there is a lot of ones.
=2Dsuppose you build a kernel without module support (this reasoning applie=
both to host and guest kernel); can you trust no module being insmoded? NO!=
There is still the /dev/kmem - /dev/mem port. Look on the net, it's a well=
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=
changes means that probably only an expert programmer can insmod through=20
/dev/kmem inside UML.
Paolo Giarrusso, aka Blaisorblade
Linux registered user n. 292729