Draft 06 James Morris 26 June 2007 Security Enhanced NFS (SENFS) Requirements - Draft 06 1. Introduction This document outlines high-level requirements for the integration of SELinux [1] functionality into NFSv4 [2]. SELinux, an implementation of the Flask security architecture [3], provides a flexible and comprehensive Mandatory Access Control (MAC) framework for the Linux operating system. This framework has been ported to several other operating systems, including Darwin [4] and BSD [5]. 2. Problem Statement SELinux currently supports per-object labeling of filesystem objects through the use of Linux Extended Attributes (EAs) [6]. This provides filesystem labeling portability, and a unified API and mechanism for storing and retrieving security labels associated with each filesystem object. For filesystems which do not support EAs, other labeling mechanisms have been devised, such as genfs, which performs labeling based upon the filesystem type and optionally also by pathname; and mountpoint labeling, which allows the security labels for all objects within a filesystem to be specified as a mount option. Labeling for NFS mounts under SELinux currently defaults to the genfs mechanism, and is often customized via mountpoint labeling. While this allows SELinux policy to provide coverage of NFS mounts, there are several limitations, including: o Labeling granularity is generally too coarse when applied to the entire filesystem. o Pathname labeling for NFS mounted files is not a general solution, and is only reliable if the exported namespace is static. o Any underlying security labeling of the exported filesystem is not conveyed over the network. o Security labels cannot be set on the remote filesystem by the client. The broad purpose of SENFS is to address these limitations by providing distributed per-object security labeling of NFS mounted filesystems. 3. Requirements The following initial requirements have been gathered from users, developers, and from previous development efforts in this area such as DTOS [7] and NSA's experimental NFSv3 enhancements [8]. Note that while these requirements are SELinux-specific, the final design may utilize a generic security labeling layer ("Labeled NFS"), with SENFS specified as one profile. 3.1. Community Acceptance SENFS must be designed and implemented in a manner which is acceptable to several upstream communities, including: o SELinux o Linux kernel o Linux NFS o IETF o Non-Linux OSes with SE implementations SENFS must be designed to ensure compliance with IETF extensibility requirements for NFSv4 and similarly for any related standards. A specification for SENFS should be developed with the aim of becoming an IETF standard. The design and implementation also must pass acceptance in upstream development communities, and not require the use of external patches or modules. Potential non-Linux implementors should be consulted for feedback on the design of SENFS. 3.2. Portability SENFS must be designed with portability in mind, to facilitate implementations on non-Linux OSes which support the SELinux model. 3.3. Interoperability SENFS must be designed and developed to facilitate interoperability between different SENFS implementations. SENFS modifications to standard NFSv4 implementations must not adversely impact any existing interoperability of those implementations. 3.4. Performance Security mechanisms often impact on system performance. SENFS should be designed and implemented in a way which avoids significant performance impact where possible. 3.5. Scalability As NFSv4 is designed for large-scale distributed networking, SENFS should also be capable of scaling in a similar manner to underlying implementations where possible. 3.6. Resilience SENFS should be respond in a robust manner to system and network outages associated with typical enterprise and Internet environments. At the very least, SENFS should always operate in a fail-safe manner, so that service disruptions do not cause or facilitate security vulnerabilities. 3.7. Security Services SENFS must ensure that the following security services are provided for all NFSv4 messaging: o Authentication o Integrity o Privacy Mechanisms and algorithms used in the provision of security services must be configurable, so that appropriate levels of protection may be flexibly specified per mandatory security policy. Strong mutual authentication will be required between the server and the client for Full Mode operation (see 3.11 Modes of Operation). Security services should be implemented according to IETF or other appropriate standards. SELinux security labels and any related security state must always be protected by these security services when transferred over the network; as must the binding of labels and state to associated objects and subjects. SENFS should support authentication on a per-domain granularity so that different domains running on a client can use different cryptographic keys and facilities. 3.8. Encoding Encoding of SELinux labels and attributes passed over the network must be specified in a complete and unambiguous manner. 3.9. Domains of Interpretation In SELinux, a Domain of Interpretation (DOI) represents an administrative security boundary, where all systems within the DOI have semantically coherent labeling. That is, a security label must always mean exactly the same thing anywhere within the DOI. An SELinux DOI may be further demarcated for any other administrative purpose. SENFS must provide a means for servers and clients to identify their DOIs for the purposes of authorization, security service selection, and security label interpretation. A negotiation scheme should be provided, allowing systems from different DOIs to agree on how they will interpret or translate each others labels. Multiple concurrent DOI agreements may be current between a server and a client. All security labels and related security state transferred across the network must be tagged with a valid DOI. If the DOI of a system changes, it should renegotiate any DOI agreements to reflect the new DOI. If a system receives any security label or security state tagged with a DOI it does not recognize or cannot interpret, it must reject that label or state. NFSv4 includes features which may cause a client to cross a DOI boundary when accessing what appears to be a single filesystem. If DOI negotiation is supported by the client and the server, the server should negotiate a new, concurrent DOI agreement with the client, acting on behalf of the externally located source of the files. SENFS should define an initial DOI negotiation scheme and DOI format with the primary aims of simplicity and completeness. This is to facilitate practical deployment of multi-DOI systems without being weighed down by complex and over-generalized global schemes. Future extensibility should also be taken into consideration. 3.10. Auditing The capability must exist for all security-relevant events within an SENFS implementation to be logged for audit purposes. SENFS should utilize the system's security audit subsystem if available, or otherwise default to logging via the most reliable mechanism available. 3.11. Modes of Operation SENFS must cater for two potentially concurrent operating modes, depending on the state of SELinux functionality: 3.11.1 Full Mode Both the server and the client have SELinux enabled, and full SENFS functionality is extended over the network between both client and server. If the client is operating in permissive mode, any delegated server policy must still be enforced; otherwise all caching and delegation must be disabled. If the server is running in permissive mode, access control extended over the network must operate as if enforcing mode is enabled. There is no permissive mode equivalent for client SENFS access. If the client process specifies mountpoint labeling for an NFS mount, then it must not also operate in Full Mode for that mount, and instead operate in Guest Mode (see below). SENFS configuration must override mountpoint labeling requests, and if there is a conflict, the mount operation must fail. 3.11.2 Guest Mode Only one of the server or client has SELinux enabled. In the case of the server only having SELinux enabled, the server locally enforces its policy, and may selectively provide standard NFS services to clients based on their authentication credentials and/or associated network attributes (e.g. IP address, network interface) according to security policy. The level of trust and access extended to a client in this mode is configuration-specific. As for Full Mode, if the server is running in permissive mode, access control extended over the network must operate as if enforcing mode is enabled. In the case of the client only having SELinux enabled, the client must operate as a standard NFSv4 client, and should selectively provide local domains access to servers based upon the security attributes of the local domains, and network attributes of the server, according to policy. The client may also override default labeling of the remote filesystem based upon these security attributes, according to policy. In other words, Guest Mode is standard NFSv4 over the wire, but with the SELinux-enabled peer optionally using fine-grained mandatory policy to provide enhanced local security labeling and access control. 3.12. Labeling Implementations must validate security labels supplied over the network to ensure that they are within a set of labels permitted from a specific peer, and if not, reject them. Note that a system may permit a different set of labels to be accepted from each peer. 3.12.1 Client Labeling At the client, labeling semantics for NFS mounted filesystems must remain consistent with those for locally mounted filesystems. In particular, user-level labeling operations local to the client must be enacted locally via the Extended Attribute system call API, to ensure compatibility and consistency for applications and libraries. Note that this does not imply any specific mechanism for conveying labels over the network. When an object is newly created by the client, the correct security label for the file must be determined by server policy (or overridden by the creating process's fscreate attribute if authorized by server policy), and bound to the object before the object becomes visible to the rest of the system. This ensures that any access control or further labeling decisions are correct for the object. All object labeling semantics must be identified in a complete manner, then mapped to SENFS operational behaviors. 3.12.2 Server Labeling SENFS servers must not return a successful response if a client attempts to set a security label on a filesystem object where the underlying filesystem does not support stable storage of security labels. Furthermore; any operation invoked by the client which involves any change to a security label on the server must not return successfully until that label is committed to stable storage. The server must provide the capability for clients to retrieve security labels on all exported filesystem objects where possible. This includes cases where only in-core and/or read-only security labels are available at the server for any of its exported filesystems. The server must honor the fscreate attribute of a process on the client if permitted by server policy. The fscreate attribute is used by privileged security-aware applications, where created objects are labeled atomically with a specific security label instead of using local labeling policy. Labeling on by the server must also take into account any other volatile client security state, such as a change in process security context via dynamic transition. 3.13. Policy Enforcement 3.13.1. Full Mode The server must enforce its local security policy over all exported objects, for operations which originate both locally and remotely. Requests from authenticated clients must be processed using security labels and credentials supplied by the client as if they originated locally. As with labeling, the server must also take into account any other volatile client security state, such as a change in process security context via dynamic transition. Access decisions should also be made based upon the current client domain accessing the object, rather than the domain which opened it, if different. The client must apply its own policy to remotely located objects, using security labels for the objects obtained from the server. It must be possible to configure the maximum length of time a client may cache state regarding remote labels before revalidating that state with the server. The server must recall delegation of an object if the object's security label changes. A mechanism must exist to allow the client to obtain access and labeling decisions from the server for locally cached and delegated objects, so that it may apply the server's policy to these objects. If the server's policy changes, the client must flush all object state back to the server. The server must ensure that any flushed state received is consistent with current policy before committing it to stable storage. Any local security state associated with cached or delegated objects must also be flushed back to the server when any other state of the objects is required to be flushed back. SENFS implementations should provide a mechanism to convey audit messages from the server to the client, so that a remote access denial or other significant event may be fully understood at the client. 3.13.2. Guest Mode The server must not accept security labels or credentials provided by the client, and only enforce its local policy to exported objects. 3.14. Namespace Access The server should provide a means to authorize selective access to the exported filesystem namespace based upon client credentials and according to security policy. This is a common requirement of MLS-enabled systems, which often need to present selective views of namespaces based upon the clearances of the subjects. 3.16. Referrals SENFS will not initially provide explicit support for NFSv4.1 referrals, although may do so in a future version. 3.18. Server Mediation Care must be taken to ensure that SELinux mediation of the NFS server is always correct in relation to whether it is acting on behalf of the client or itself, and that there are no mediation gaps arising from security bypasses intended for previously non-SENFS aware kernel components of the NFS subsystem, where applicable. 3.19. Preservation of Existing Behavior SENFS modifications made to existing NFS implementations must ensure that existing behavior is preserved if SELinux is disabled at either compile or run time. 4. Next Steps The intention is to subject these requirements to several iterations of review from an increasingly wider audience. Once there is consensus on the requirements, a functional specification will be designed and also subjected to review, ideally in parallel with prototyping. 5. Author Contact James Morris 6. Acknowledgments The following people provided valuable feedback during the development of this document: Stephen Smalley, NSA James Carter, NSA Karl MacMillan, Red Hat Inc. J. Bruce Fields. Paul Moore, HP. 7. References [1] Security Enhanced Linux (SELinux) http://www.nsa.gov/selinux/ [2] RFC3530, Network File System (NFS) version 4 Protocol http://www.ietf.org/rfc/rfc3530.txt [3] The Flask Security Architecture: System Support for Diverse Security Policies http://www.cs.utah.edu/flux/papers/flask-usenixsec99-abs.html [4] SEDarwin: Security Enhanced Darwin http://www.sedarwin.org/ [5] SEBSD: Port of SELinux FLASK and Type Enforcement to TrustedBSD http://www.trustedbsd.org/sebsd.html [6] Linux Extended Attributes and ACLs http://acl.bestbits.at/ [7] The Distributed Trusted Operating System (DTOS) Home Page http://www.cs.utah.edu/flux/fluke/html/dtos/HTML/dtos.html [8] Implementing SELinux Support for NFS http://www.nsa.gov/selinux/papers/nfsv3-abs.cfm