[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ietf-nfsv4
Subject:    RE: [nfsv4] Named attributes and getxattr
From:       Robert Watson <rwatson () FreeBSD ! org>
Date:       2005-11-17 18:10:36
Message-ID: 20051117175951.J1109 () fledge ! watson ! org
[Download RAW message or body]


On Thu, 17 Nov 2005, Gordon Waidhofer wrote:

>> We have support for at least four mandatory access control models in 
>> FreeBSD that use extended attributes -- Biba integrity, MLS 
>> confidentiality, and SEBSD (type enforcement), as well as a checksum 
>> verification policy for binary execution.  These plug in using our MAC 
>> Framework and are (almost entirely) implemented above the file system 
>> layer.  This is exactly the sort of service that would benefit from an 
>> NFSv4 attribute service providing an equivilent to the Linux/Mac OS 
>> X/IRIX/FreeBSD/HPFS extended attribute meta-data storage service.  In 
>> fact, in order to carry MAC labels in NFS, we have an immediate desire 
>> to have something like that.  And on looking at named attributes, we 
>> rapidly became concerned that although this was a useful way to expose 
>> a sub-file semantic, we actually wanted a meta-data semantic not a 
>> sub-file semantic for this purpose.
>
> Are the MAC labels interpretted and enforced above or below the kernel 
> interface? I'm not sure how "mandatory" is handled by the library level. 
> Are the MAC labels sensitive to endianess?

For files/directories, the protections are enforced by the kernel, 
although applications help to set and maintain the labels using a set of 
label manipulation system calls, which are translated into extended 
attribute operations by a combination of the MAC Framework and policy 
module implementation the policy.  Labels, as manipulated by applications, 
are actually text strings, so endian-independent.  As currently stored in 
local file systems, it depends on the policy, but for most policies they 
are stored in machine-local format.  In experimental work to push them 
over the network, they are in transported in the same string format used 
in user space.  In general, in FreeBSD, file systems don't participate 
directly in the enforcement of policies, as that occurs in the cross-file 
system VFS code in the kernel.

In our work to bring mandatory access control to Darwin, we found that we 
did need to perform some enforcement in the local file system code due to 
the presence of complex compound operations that were insufficiently 
visible in the file system independent code -- i.e., operations to search 
the disk catalog, set attributes on multiple objects, etc.  However, the 
checks in those cases are not done directly using the extended attributes, 
rather, a cache of the label hung off the vnode in internalized form (a 
format in which access decisions can be computed efficiently).

With NFSv3, and carrying over to NFSv4, we basically identified three sets 
of technical requirements to carry label data on the wire for files: (1) 
finding a way to transfer the label data, (2) having a way to address 
cache consistency for the label data in order to propagate changes to 
cached labels, and (3) a mechanism for atomic update, as read-modify-write 
operations on labels have atomicity requirements for the security check on 
a relabel event.  In this work, we did not look at requirements for 
transfering subject labels (credential extensions) on the wire.

Robert N M Watson

_______________________________________________
nfsv4 mailing list
nfsv4@ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4
[prev in list] [next in list] [prev in thread] [next in thread]