[libvirt] [PATCH] Added new attribute security_model to filesystem element

[Venkateswararao Jujjuri (JV)]

On 10/7/2010 7:20 AM, Daniel Veillard wrote:
> On Sat, Sep 25, 2010 at 12:04:11AM +0530, Harsh Prateek Bora wrote:
>> This patch introduces new attribute to filesystem element
>> to support customizable security_model for mount type.
>> Valid security_model are: passthrough, mapped and none.
>>
>> Usage:
>> 	<filesystem type='mount' security_model='passthrough'>
>> 	<source dir='/export/to/guest'/>
>> 	<target dir='mount_tag'/>
>> 	</filesystem>
> 
>   Well, there is a missing documentation part in the patch.
> In what way does having security_model='passthrough',
> security_model='mapped' or security_model='none' change the
> behaviour of the library compared to not having the attribute at
> all.

I think we can ignore "none" and stick to mapped and passthrough for now.
The security model is a mandatory argument for QEMU to start 9p/virtfs exports

Here is the detailed explanation on these security models:


Security model: mapped
----------------------

Fileserver intercepts and maps all the file object create requests.
Files on the fileserver will be created with Fileserver's user credentials and the
client-user's credentials are stored in extended attributes.
During getattr() server extracts the client-user's credentials from extended
attributes and sends to the client.

This adds a great deal of security in the cloud environments where the
guest's(client) user space is kept completely isolated from host's user space.


Security model : passthrough
----------------------------

In this security model, Fileserver passes down all requests to the
underlying filesystem. File system objects on the fileserver will be created
with client-user's credentials. This is done by setting setuid()/setgid()
during creation or chmod/chown after file creation. At the end of create protocol
request, files on the fileserver will be owned by cleint-user's uid/gid.
This model mimic's current NFSv3 level of security.



>   Any patch which modifies the API (and the XML is part of the API)
> must have a clearly defined semantic, and that definition (and if
> possible an example) must be provided in the set of patches for the
> documentation.
>   We cannot accept a patch whose only semantic is "add a given QEmu
> command line argument" because it makes impossible to try to support
> the option on other hypervisor or if QEmu end up changing the command
> line.

Our need for different security models is because of the different domains we
or any other paravirtual filesystem may need to serve.

"mapped" model is targeted for  domains which
demands a complete isolation of guest user domain from
that of the hosts hence practically eliminating any security
issues related to setuid/setgid and root. This is a
very practical use case for certain classes of cloud workloads
where multi-tenancy is a requirement. A complete
isolation of user domain can practically make two competing
customers share the same file system.

The "passthrough" model is to play along with the traditional
network file-serving methodologies like NFS and CIFS
by sharing user domains of the host and guest. This
method edges out by offering flexibility to export the
same file system through other network file systems
along with VirtFS.

> 
>   What is your patch providing in term of API ?

Does my explanation above answers your questions?
If not, I guess I am not very clear about this question.
The code is already in the QEMU mainline and I don't expect the options
to change. I also assume that other hypervisors may have to have
some level of security models defined to serve different needs.

Thanks,
JV

> 
> Daniel
>