Re: [Qemu-devel] [PATCH-V5 0/10] virtio-9p:Introducing security model for VirtFS

[Venkateswararao Jujjuri (JV)]

Blue Swirl wrote:
> On Sat, Jun 5, 2010 at 1:08 AM, Venkateswararao Jujjuri (JV)
> <address@hidden> wrote:
>> This patch series introduces the security model for VirtFS.
>>
>> Brief description of this patch series:
>>
>> It introduces two type of security models for VirtFS.
>> They are: mapped and passthrough.
>>
>> The following is common to both security models.
>>
>> * Client's VFS determines/enforces the access control.
>>  Largely server should never return EACCESS.
>>
>> * Client sends gid/mode-bit information as part of creation only.
>>
>> Changes from V4
>> ---------------
>> o Most of the cosmetic changes proposed by Aneesh.
>> o Divided into more number of patches and added more explanation to each 
>> patch.
>>
>> Changes from V3
>> ---------------
>> o Return NULL instead of exit(1) on failure in virtio_9p_init()
>> o Capitalized sm_passthrough, sm_mappe
>> o Added handling for EINTR for read/write.
>> o Corrected default permissions for mkdir in mapped mode.
>> o Added additional error handling.
>>
>> Changes from V2
>> ---------------
>> o Removed warnings resulting from chmod/chown.
>> o Added code to fail normally if secuirty_model option is not specified.
>>
>> Changes from V1
>> ---------------
>> o Added support for chmod and chown.
>> o Used chmod/chown to set credentials instead of setuid/setgid.
>> o Fixed a bug where uid used instated of uid.
>>
>>
>> Security model: mapped
>> ----------------------
>>
>> VirtFS server(QEMU) intercepts and maps all the file object create requests.
>> Files on the fileserver will be created with QEMU'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.
>>
>> Given that only the user space extended attributes are available to regular
>> files, special files are created as regular files on the fileserver and the
>> appropriate mode bits are stored in xattrs and will be extracted during
>> getattr.
>>
>> If the extended attributes are missing, server sends back the filesystem
>> stat() unaltered. This provision will make the files created on the
>> fileserver usable to client.
>>
>> Points to be considered
>>
>> * Filesystem will be VirtFS'ized. Meaning, other filesystems may not
>>  understand the credentials of the files created under this model.
>>
>> * Regular utilities like 'df' may not report required results in this model.
>>  Need for special reporting utilities which can understand this security 
>> model.
> 
> Just some thought: This part could have other uses too, for example
> vext3 would be more useful than vvfat. Also VFAT attributes
> hidden/system/archived could be implemented with extended attributes.
> 
> Another point to consider is that this will be Linux specific, if my
> earlier patch to make v9fs available to all Posix systems makes sense,
> this part should be conditional.

The protocol we are developing is 9P2000.L, which is Linux specific protocol.
You mean there could be some Posix systems that doesn't support extended 
attributes?

As per this page BSDs and other systems also support extended attributes.
http://en.wikipedia.org/wiki/Extended_file_attributes

I think it is good point that before we are taking the patch to make it generic 
for all
Posix systems,  may be enable per OS and start with Linux? may be we should 
wait until it becomes more stable and feature complete on Linux? before 
considering for other OSes?

Thanks,
JV





> 
>> Security model : passthrough
>> ----------------------------
>>
>> In this security model, VirtFS server 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 ch* after file creation. At the end of create protocol
>> request, files on the fileserver will be owned by cleint-user's uid/gid.
>>
>> Points to be considered
>>
>>  * Fileserver should always run as 'root'.
>>  * Root squashing may be needed. Will be for future work.
>>  * Potential for user credential clash between guest's user space IDs and
>>    host's user space IDs.
>>
>> It also adds security model attribute to -fsdev device and to -virtfs 
>> shortcut.
> 
> I'd suppose it may be useful to also allow passthrough for non-root
> users so that for example user's home directory can be shared.
>