The title of this blog may seem like an oxymoron since the obvious security policy would be to prohibit sharing labeled files. In fact, that is the default policy in Oracle Solaris 11.4 for NFS and SMB shares since the kernel-based implementations of NFS and SMB (a.k.a. CIFS) are label-aware.  Files and directories whose labels are higher than Admin_Low are not exposed to clients. The policy for sharing labeled file systems is described here.


An NFS administrator may override this restriction by setting the option labeled=on as described in share_nfs(8). There is currently no equivalent setting for the share_smb(8) option, so the remainder of the blog will focus on NFS. The following procedure can be used to enable labeled access to an NFS share.


     # zfs set share.nfs.labeled=on rpool/export/home

     # zfs set share.nfs=on rpool/export/home


When this option is enabled, access may be granted to files and directories whose labels are dominated by the user's clearance. The user's clearance is retrieved from the NFS server's name service after mapping the NFS client's identity to a local identity. This option requires that the NFS ID Mapper service, svc:/network/nfs/mapid, is enabled. The NFS server must either have local account clearances specified in user_attr(8) or must be an LDAP client of a server containing account clearances.  The kernel maintains a cache of mappings between users and clearances so that it can efficiently perform label dominance checks. To prevent spoofing the user's identity, the NFS share should also include strong authentication, such as the use of Kerberos:


          # zfs set rpool/export/home


Oracle Solaris 11.4 supports NFS Version 4.1, but that protocol has no mechanisms for clients to get or set file labels. Newly created files and directories on the NFS server simply inherit their labels from their parent directory. The NFS 4.2 protocol does support file labeling, and specifies various label interchange mechanisms for label transmission, including CIPSO and CALIPSO. Both of these mechanisms are present in the Oracle Solaris kernel because they are required for labeled networking when Trusted Extensions is enabled. But the Trusted Extensions model requires mutual trust between peers because the peer's label is applied to newly created objects. Each trusted system must identify the peers from which it is willing to receive labeled packets. This isn't practical or necessary for standard NFS servers.


In Oracle Solaris 11.4, file labels are inherited from their parent directory, not from the client. The API to set file labels, setflabel(3TSOL), is unprivileged, but the real user must have been assigned the authorizations solaris.label.file.upgrade and/or solaris.label.file.downgrade. So in a potential implementation of NFS 4.2 Labeled NFS for Oracle Solaris, these authorization checks could be added to the NFS map ID daemon, and the results could be included in the existing kernel clearance cache. Note that the NFS server would not need to be aware of the client's label encodings (the human readable format) because the label transmission and dominance checks operate on binary label structures.