[RFC] Security Enhanced NFS (SENFS) Requirements - draft 05
James Morris
jmorris at namei.org
Wed Jun 20 16:49:45 EDT 2007
Attached is a draft requirements document for the integration of SELinux
and NFSv4 (SENFS). Also available at:
http://namei.org/selinux/nfs/senfs-requirements-draft-05.txt
This has been through a few internal iterations from the SELinux side, and
we hope to now obtain feedback from a wider audience, particularly Linux
NFS developers.
The goals at this stage are to ensure we have capture all of the
requirements correctly, and that we're on the right track in general.
Low-level implementation details are not considered in this document, and
are intended to be outlined in a subsequent functional specification, once
the requirements have been nailed down.
Please reply with any feedback.
The intention is to get SENFS on the IETF standards track, so any
assistance in that area would also be appreciated.
- James
--
James Morris
<jmorris at namei.org>
-------------- next part --------------
Draft 05
James Morris
20 June 2007
Security Enhanced NFS (SENFS) Requirements - Draft 05
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].
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.
3.15. External Remote Filesystems
Under NFSv4, filesystems located externally to the server may be
exported in the same namespace as locally exported filesystems.
SENFS will not support this initially in Full Mode, although for Guest
Mode, the server may convey locally generated security labels to the
client.
3.16. Referrals
SENFS will not initially provide explicit support for NFSv4.1
referrals, although may do so in a future version.
3.17. 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.18. 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 <jmorris at namei.org>
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.
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
More information about the NFSv4
mailing list