qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Blue Swirl
Subject: Re: [Qemu-devel] [PATCH-V5 0/10] virtio-9p:Introducing security model for VirtFS
Date: Sun, 6 Jun 2010 07:12:39 +0000

On Sat, Jun 5, 2010 at 10:50 PM, Venkateswararao Jujjuri (JV)
<address@hidden> wrote:
> 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

It looks like OpenBSD and NetBSD attributes are just a few fixed
additional bits, much like old ext2 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?

Historically the interest from BSD developers (in form of acceptably
submitted patches) has not been massive, so I wouldn't hold my breath
waiting for any BSD (or any non-Linux) attribute patches either.
Please go ahead and don't let me slow you down.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]