Carsten Otte wrote:
>
>>> Our implementation does use action bits preseted to sys_s390host_sie
>>> to update the hardware control blocks for the virutal machine. The
>>> hardware control blocks would be mapped read-only to user address
>>> space. This way, the kernel can enforce the user not to mess things
>>> up, which allows to run non-privileged user code (userid johndoe
>>> instead of root). Would this approach be reasonable on x86 too?
>>
>> Allowing the guest to hack the host userspace exposes the rest of the
>> user's processes to a malicious guest, and allows the guest to open
>> network connections through the host, no?
> The security model we had in mind was, that the user who starts the
> userspace program equals root on the guest system but does not equal
> root on the host.
> This way, we have seperate users by means of regular kernel security
> barriers in the host linux: the user johndoe is capable of messing
> with his personal virtual machines and other resources, but can not
> mess with virtual machines and other resources belonging to other
> users. If the guest root choses to be malicious, he might well be able
> to take over the userspace and mess up with whatever the user is
> allowed to do on the host.
> Frankly this does not mean we want to leave the door open for the
> guest intentionally, just that it is not an integral security issue
> for the hosting Linux if we would have a security bug.
I don't know what your usage model is, but it seems to me that leaving
the host userspace at the mercy of the guest is a fairly large security
hole:
- the guest can modify the user's files, and read other users' files
- the guest can access the host's network, possibly bypassing any
firewalling that is set up for the guest
- the guest can access other virtual machines on the host
So, if the guest is broken into, or if you download an untrusted guest
image ("virtual appliance"), then potentially large amounts of data are
at risk, even if you run as a regular user. Does your usage model allow
this?
> Looks to me, like we have different security models today. If our
> model to start guests as regular user would work on all platforms
> without causing performance penalty, I think it would be worth to do
> that extra effort. If not, we could also implement the current kvm
> security barrier and reduce complexity of our s390host code.
kvm/x86 also allows running as a regular user.
--
error compiling committee.c: too many arguments to function
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
