draft-ietf-nfsv4-labreqs-02.txt		draft-ietf-nfsv4-labreqs-03.txt
	NFSv4 T. Haynes, Ed.		NFSv4 T. Haynes, Ed.
	Internet-Draft NetApp		Internet-Draft NetApp
	Intended status: Standards Track May 11, 2012		Intended status: Standards Track May 18, 2012
	Expires: November 12, 2012		Expires: November 19, 2012
	Requirements for Labeled NFS		Requirements for Labeled NFS
	draft-ietf-nfsv4-labreqs-02.txt		draft-ietf-nfsv4-labreqs-03.txt
	Abstract		Abstract
	This Internet-Draft outlines high-level requirements for the		This Internet-Draft outlines high-level requirements for the
	integration of flexible Mandatory Access Control (MAC) functionality		integration of flexible Mandatory Access Control (MAC) functionality
	into NFSv4.2. It describes the level of protections that should be		into NFSv4.2. It describes the level of protections that should be
	provided over protocol components and the basic structure of the		provided over protocol components and the basic structure of the
	proposed system. It also gives a brief explanation of what kinds of		proposed system. It also gives a brief explanation of what kinds of
	protections MAC systems offer.		protections MAC systems offer.
	skipping to change at page 1, line 41		skipping to change at page 1, line 41
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on November 12, 2012.		This Internet-Draft will expire on November 19, 2012.
	Copyright Notice		Copyright Notice
	Copyright (c) 2012 IETF Trust and the persons identified as the		Copyright (c) 2012 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 3, line 23		skipping to change at page 3, line 23
	3.4. Label Encoding, Label Format Specifiers, and Label		3.4. Label Encoding, Label Format Specifiers, and Label
	Checking Authorities . . . . . . . . . . . . . . . . . . . 7		Checking Authorities . . . . . . . . . . . . . . . . . . . 7
	3.5. Modes of Operation . . . . . . . . . . . . . . . . . . . . 8		3.5. Modes of Operation . . . . . . . . . . . . . . . . . . . . 8
	3.5.1. Full Mode . . . . . . . . . . . . . . . . . . . . . . 8		3.5.1. Full Mode . . . . . . . . . . . . . . . . . . . . . . 8
	3.5.2. Limited Server Mode . . . . . . . . . . . . . . . . . 9		3.5.2. Limited Server Mode . . . . . . . . . . . . . . . . . 9
	3.5.3. Guest Mode . . . . . . . . . . . . . . . . . . . . . . 9		3.5.3. Guest Mode . . . . . . . . . . . . . . . . . . . . . . 9
	3.6. Labeling . . . . . . . . . . . . . . . . . . . . . . . . . 9		3.6. Labeling . . . . . . . . . . . . . . . . . . . . . . . . . 9
	3.6.1. Client Labeling . . . . . . . . . . . . . . . . . . . 10		3.6.1. Client Labeling . . . . . . . . . . . . . . . . . . . 10
	3.6.2. Server Labeling . . . . . . . . . . . . . . . . . . . 10		3.6.2. Server Labeling . . . . . . . . . . . . . . . . . . . 10
	3.7. Policy Enforcement . . . . . . . . . . . . . . . . . . . . 10		3.7. Policy Enforcement . . . . . . . . . . . . . . . . . . . . 10
	3.7.1. Full Mode . . . . . . . . . . . . . . . . . . . . . . 10		3.7.1. Client Enforcement . . . . . . . . . . . . . . . . . . 11
	3.7.2. Guest Mode . . . . . . . . . . . . . . . . . . . . . . 11		3.7.2. Server Enforcement . . . . . . . . . . . . . . . . . . 11
	3.8. Namespace Access . . . . . . . . . . . . . . . . . . . . . 11		3.8. Namespace Access . . . . . . . . . . . . . . . . . . . . . 11
	3.9. Upgrading Existing Server . . . . . . . . . . . . . . . . 12		3.9. Upgrading Existing Server . . . . . . . . . . . . . . . . 12
	4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 12		4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 12
	4.1. Full MAC labeling support for remotely mounted		4.1. Full MAC labeling support for remotely mounted
	filesystems . . . . . . . . . . . . . . . . . . . . . . . 12		filesystems . . . . . . . . . . . . . . . . . . . . . . . 12
	4.2. MAC labeling of virtual machine images stored on the		4.2. MAC labeling of virtual machine images stored on the
	network . . . . . . . . . . . . . . . . . . . . . . . . . 12		network . . . . . . . . . . . . . . . . . . . . . . . . . 12
	4.3. International Traffic in Arms Regulations (ITAR) . . . . . 13		4.3. International Traffic in Arms Regulations (ITAR) . . . . . 13
	4.4. Legal Hold/eDiscovery . . . . . . . . . . . . . . . . . . 13		4.4. Legal Hold/eDiscovery . . . . . . . . . . . . . . . . . . 13
	4.5. Simple security label storage . . . . . . . . . . . . . . 14		4.5. Simple security label storage . . . . . . . . . . . . . . 14
	4.6. Diskless Linux . . . . . . . . . . . . . . . . . . . . . . 14		4.6. Diskless Linux . . . . . . . . . . . . . . . . . . . . . . 14
	4.7. Multi-Level Security . . . . . . . . . . . . . . . . . . . 15		4.7. Multi-Level Security . . . . . . . . . . . . . . . . . . . 15
	4.7.1. Full Mode - MAC-functional Client and Server . . . . . 15		4.7.1. Full Mode - MAC-functional Client and Server . . . . . 15
	4.7.2. MAC-Functional Client . . . . . . . . . . . . . . . . 16		4.7.2. MAC-Functional Client . . . . . . . . . . . . . . . . 16
	4.7.3. MAC-Functional Server . . . . . . . . . . . . . . . . 16		4.7.3. MAC-Functional Server . . . . . . . . . . . . . . . . 16
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 17		5. Security Considerations . . . . . . . . . . . . . . . . . . . 17
	5.1. Guest Modes . . . . . . . . . . . . . . . . . . . . . . . 17		5.1. Trust Needed for a Community . . . . . . . . . . . . . . . 17
	5.2. MAC-Functional Client Configuration . . . . . . . . . . . 17		5.2. Guest Modes . . . . . . . . . . . . . . . . . . . . . . . 17
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17		5.3. MAC-Functional Client Configuration . . . . . . . . . . . 17
			6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18		7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
	7.1. Normative References . . . . . . . . . . . . . . . . . . . 18		7.1. Normative References . . . . . . . . . . . . . . . . . . . 18
	7.2. Informative References . . . . . . . . . . . . . . . . . . 18		7.2. Informative References . . . . . . . . . . . . . . . . . . 18
	Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 18		Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 19
	Appendix B. RFC Editor Notes . . . . . . . . . . . . . . . . . . 19		Appendix B. RFC Editor Notes . . . . . . . . . . . . . . . . . . 19
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19
	1. Introduction		1. Introduction
	Mandatory Access Control (MAC) systems have been mainstreamed in		Mandatory Access Control (MAC) systems have been mainstreamed in
	modern operating systems such as Linux (R), FreeBSD (R), and Solaris		modern operating systems such as Linux (R), FreeBSD (R), and Solaris
	(TM). MAC systems bind security attributes to subjects (processes)		(TM). MAC systems bind security attributes to subjects (processes)
	and objects within a system. These attributes are used with other		and objects within a system. These attributes are used with other
	information in the system to make access control decisions.		information in the system to make access control decisions.
	skipping to change at page 5, line 26		skipping to change at page 5, line 26
	Object: is a passive resource within the system that we wish to be		Object: is a passive resource within the system that we wish to be
	protected. Objects can be entities such as files, directories,		protected. Objects can be entities such as files, directories,
	pipes, sockets, and many other system resources relevant to the		pipes, sockets, and many other system resources relevant to the
	protection of the system state.		protection of the system state.
	Subject: is an active entity, usually a process, which is requesting		Subject: is an active entity, usually a process, which is requesting
	access to an object.		access to an object.
	MAC-Aware: is a server which can transmit and store object labels.		MAC-Aware: is a server which can transmit and store object labels.
	MAC-Functional: is a client or server which is LNFS enabled. Such a		MAC-Functional: is a client or server which is Labeled NFS enabled.
	system can interpret labels and apply policies based on the		Such a system can interpret labels and apply policies based on the
	security system.		security system.
	Multi-Level Security (MLS): is a traditional model where objects are		Multi-Level Security (MLS): is a traditional model where objects are
	given a sensitivity level (Unclassified, Secret, Top Secret, etc)		given a sensitivity level (Unclassified, Secret, Top Secret, etc)
	and a category set [5].		and a category set [5].
	3. Requirements		3. Requirements
	The following initial requirements have been gathered from users,		The following initial requirements have been gathered from users,
	developers, and from previous development efforts in this area such		developers, and from previous development efforts in this area such
	as DTOS [6] and NSA's experimental NFSv3 enhancements [7].		as DTOS [6] and NSA's experimental NFSv3 enhancements [7].
	3.1. Portability & Interoperability		3.1. Portability & Interoperability
	LNFS MUST be designed with portability in mind, to facilitate		Labeled NFS MUST be designed with portability in mind, to facilitate
	implementations on any operating system that supports mandatory		implementations on any operating system that supports mandatory
	access controls.		access controls.
	LNFS MUST be designed and developed to facilitate interoperability		Labeled NFS MUST be designed and developed to facilitate
	between different LNFS implementations.		interoperability between different Labeled NFS implementations.
	LNFS modifications to standard NFSv4.2 [3] implementations MUST not		Labeled NFS modifications to standard NFSv4.2 [3] implementations
	adversely impact any existing interoperability of those		MUST not adversely impact any existing interoperability of those
	implementations.		implementations.
	3.2. Performance & Scalability		3.2. Performance & Scalability
	Security mechanisms often impact on system performance. LNFS SHOULD		Security mechanisms often impact on system performance. Labeled NFS
	be designed and implemented in a way which avoids significant		SHOULD be designed and implemented in a way which avoids significant
	performance impact where possible.		performance impact where possible.
	As NFSv4.2 is designed for large-scale distributed networking, LNFS		As NFSv4.2 is designed for large-scale distributed networking,
	SHOULD also be capable of scaling in a similar manner to underlying		Labeled NFS SHOULD also be capable of scaling in a similar manner to
	implementations where possible.		underlying implementations where possible.
	LNFS SHOULD respond in a robust manner to system and network outages		Labeled NFS SHOULD respond in a robust manner to system and network
	associated with typical enterprise and Internet environments. At the		outages associated with typical enterprise and Internet environments.
	very least, LNFS SHOULD always operate in a fail-safe manner, so that		At the very least, Labeled NFS SHOULD always operate in a fail-safe
	service disruptions do not cause or facilitate security		manner, so that service disruptions do not cause or facilitate
	vulnerabilities.		security vulnerabilities.
	3.3. Security Services		3.3. Security Services
	LNFS SHOULD ensure that the following security services are provided		Labeled NFS SHOULD ensure that the following security services are
	for all NFSv4.2 messaging. These services may be provided by lower		provided for all NFSv4.2 messaging. These services may be provided
	layers even if NFS has to be aware of and leverage them:		by lower layers even if NFS has to be aware of and leverage them:
	o Authentication		o Authentication
	o Integrity		o Integrity
	o Privacy		o Privacy
	Mechanisms and algorithms used in the provision of security services		Mechanisms and algorithms used in the provision of security services
	MUST be configurable, so that appropriate levels of protection may be		MUST be configurable, so that appropriate levels of protection may be
	flexibly specified per mandatory security policy.		flexibly specified per mandatory security policy.
	Strong mutual authentication will be required between the server and		Strong mutual authentication will be required between the server and
	the client for Full Mode operation Section 3.5.1.		the client for Full Mode operation Section 3.5.1.
	MAC security labels and any related security state SHOULD always be		MAC security labels and any related security state SHOULD always be
	protected by these security services when transferred over the		protected by these security services when transferred over the
	network; as SHOULD the binding of labels and state to associated		network; as SHOULD the binding of labels and state to associated
	objects and subjects.		objects and subjects.
	LNFS SHOULD support authentication on a context granularity so that		Labeled NFS SHOULD support authentication on a context granularity so
	different contexts running on a client can use different		that different contexts running on a client can use different
	cryptographic keys and facilities.		cryptographic keys and facilities.
	3.4. Label Encoding, Label Format Specifiers, and Label Checking		3.4. Label Encoding, Label Format Specifiers, and Label Checking
	Authorities		Authorities
	Encoding of MAC labels and attributes passed over the network MUST be		Encoding of MAC labels and attributes passed over the network MUST be
	specified in a complete and unambiguous manner while maintaining the		specified in a complete and unambiguous manner while maintaining the
	flexibility of MAC implementations. To accomplish this the labels		flexibility of MAC implementations. To accomplish this the labels
	MUST consist of an opaque component bound with a Label Format		MUST consist of an opaque component bound with a Label Format
	Specifier (LFS). The LFS component provides a mechanism for		Specifier (LFS). The LFS component provides a mechanism for
	skipping to change at page 7, line 25		skipping to change at page 7, line 25
	interpreted by the MAC models.		interpreted by the MAC models.
	MAC models base access decisions on security attributes bound to		MAC models base access decisions on security attributes bound to
	subjects and objects. With a given MAC model, all systems have		subjects and objects. With a given MAC model, all systems have
	semantically coherent labeling - a security label MUST always mean		semantically coherent labeling - a security label MUST always mean
	exactly the same thing on every system. While this may not be		exactly the same thing on every system. While this may not be
	necessary for simple MAC models it is recommended that most label		necessary for simple MAC models it is recommended that most label
	formats assigned an LFS incorporate this concept into their label		formats assigned an LFS incorporate this concept into their label
	format.		format.
	LNFS MUST provide a means for servers and clients to identify their		Labeled NFS MUST provide a means for servers and clients to identify
	LFS for the purposes of authorization, security service selection,		their LFS for the purposes of authorization, security service
	and security label interpretation.		selection, and security label interpretation.
	A negotiation scheme SHOULD be provided, allowing systems from		A negotiation scheme SHOULD be provided, allowing systems from
	different label formats to agree on how they will interpret or		different label formats to agree on how they will interpret or
	translate each others labels. Multiple concurrent agreements may be		translate each others labels. Multiple concurrent agreements may be
	current between a server and a client.		current between a server and a client.
	All security labels and related security state transferred across the		All security labels and related security state transferred across the
	network MUST be tagged with a valid LFS.		network MUST be tagged with a valid LFS.
	If the LFS supported on a system changes, it SHOULD renegotiate		If the LFS supported on a system changes, it SHOULD renegotiate
	skipping to change at page 7, line 50		skipping to change at page 7, line 50
	If a system receives any security label or security state tagged with		If a system receives any security label or security state tagged with
	an LFS it does not recognize or cannot interpret, it MUST reject that		an LFS it does not recognize or cannot interpret, it MUST reject that
	label or state.		label or state.
	NFSv4.2 includes features which may cause a client to cross an LFS		NFSv4.2 includes features which may cause a client to cross an LFS
	boundary when accessing what appears to be a single file system. If		boundary when accessing what appears to be a single file system. If
	LFS negotiation is supported by the client and the server, the server		LFS negotiation is supported by the client and the server, the server
	SHOULD negotiate a new, concurrent agreement with the client, acting		SHOULD negotiate a new, concurrent agreement with the client, acting
	on behalf of the externally located source of the files.		on behalf of the externally located source of the files.
	LNFS SHOULD define an initial negotiation scheme with the primary		Labeled NFS SHOULD define an initial negotiation scheme with the
	aims of simplicity and completeness. This is to facilitate practical		primary aims of simplicity and completeness. This is to facilitate
	deployment of systems without being weighed down by complex and over-		practical deployment of systems without being weighed down by complex
	generalized global schemes. Future extensibility SHOULD also be		and over-generalized global schemes. Future extensibility SHOULD
	taken into consideration.		also be taken into consideration.
	3.5. Modes of Operation		3.5. Modes of Operation
	In a LNFS client and server interaction, we can describe three modes		In a Labeled NFS client and server interaction, we can describe three
	of operation:		modes of operation:
	1. Full		1. Full
	2. Limited Server		2. Limited Server
	3. Guest		3. Guest
	These modes arise from the level of MAC functionality in the clients		These modes arise from the level of MAC functionality in the clients
	and servers. The clients can be non-MAC-Functional and MAC-		and servers. The clients can be non-MAC-Functional and MAC-
	Functional. The servers can be non-MAC-Functional, MAC-Aware, and		Functional. The servers can be non-MAC-Functional, MAC-Aware, and
	MAC-Functional.		MAC-Functional.
	A MAC-Functional client MUST be able to determine the level of MAC		A MAC-Functional client MUST be able to determine the level of MAC
	functionality in the server. Likewise, a MAC-Functional server MUST		functionality in the server. Likewise, a MAC-Functional server MUST
	be able to determine whether or not a client is MAC-Functional.		be able to determine whether or not a client is MAC-Functional.
	3.5.1. Full Mode		3.5.1. Full Mode
	The server and the client have mutually recognized MAC functionality		The server and the client have mutually recognized MAC functionality
	enabled, and full LNFS functionality is extended over the network		enabled, and full Labeled NFS functionality is extended over the
	between both client and server.		network between both client and server.
	An example of an operation in full mode is as follows. On the		An example of an operation in full mode is as follows. On the
	initial lookup, the client requests access to an object on the		initial lookup, the client requests access to an object on the
	server. It sends its process security context over to the server.		server. It sends its process security context over to the server.
	The server checks all relevant policies to determine if that process		The server checks all relevant policies to determine if that process
	context from that client is allowed to access the resource. Once		context from that client is allowed to access the resource. Once
	this has succeeded the object with its associated security		this has succeeded the object with its associated security
	information is released to the client. Once the client receives the		information is released to the client. Once the client receives the
	object it determines if its policies allow the process running on the		object it determines if its policies allow the process running on the
	client access to the object.		client access to the object.
	skipping to change at page 9, line 14		skipping to change at page 9, line 14
	everything succeeds.		everything succeeds.
	In the event that the client does not trust the server, it may opt to		In the event that the client does not trust the server, it may opt to
	use an alternate labeling mechanism regardless of the server's		use an alternate labeling mechanism regardless of the server's
	ability to return security information.		ability to return security information.
	3.5.2. Limited Server Mode		3.5.2. Limited Server Mode
	The server is MAC-Aware and the clients are MAC-Functional. The		The server is MAC-Aware and the clients are MAC-Functional. The
	server can store and transmit labels. It cannot enforce labels. The		server can store and transmit labels. It cannot enforce labels. The
	server SHOULD inform clients when an object label changes for a file		server MUST inform clients when an object label changes for a file
	the client has open.		the client has open.
	In this mode, the server may not be aware of the format of any its		In this mode, the server may not be aware of the format of any its
	object labels. Indeed, it may service several different security		object labels. Indeed, it may service several different security
	models at the same time. A client MUST process foreign labels as		models at the same time. A client MUST process foreign labels as
	discussed in Section 3.4. As with the Guest Mode, this mode's level		discussed in Section 3.4. As with the Guest Mode, this mode's level
	of trust can be degraded if non-MAC-functional clients have access to		of trust can be degraded if non-MAC-functional clients have access to
	the server.		the server.
	3.5.3. Guest Mode		3.5.3. Guest Mode
	skipping to change at page 10, line 45		skipping to change at page 10, line 45
	The server MUST honor the ability for a client to specify the label		The server MUST honor the ability for a client to specify the label
	of an object on creation. If the server is MAC enabled it may choose		of an object on creation. If the server is MAC enabled it may choose
	to reject the label specified by the client due to restrictions in		to reject the label specified by the client due to restrictions in
	the server policy. The server SHOULD not attempt to find a suitable		the server policy. The server SHOULD not attempt to find a suitable
	label for an object in event of different labeling rules on its end.		label for an object in event of different labeling rules on its end.
	The server is allowed to translate the label but SHOULD not change		The server is allowed to translate the label but SHOULD not change
	the semantic meaning of the label.		the semantic meaning of the label.
	3.7. Policy Enforcement		3.7. Policy Enforcement
	3.7.1. Full Mode		The MAC-Functional client determines if a process request is sent to
			the remote server. Upon a successful response from the server, it
	The server MUST enforce its security policy over all exported		must use its own policies on the object's security labels to
	objects, for operations which originate both locally and remotely.		determine if the process can be given access. The client SHOULD not
			need to be cognizant if the server is either a Limited Server or
	Requests from authenticated clients MUST be processed using security		fully MAC-Functional.
	labels and credentials supplied by the client as if they originated
	locally.
	As with labeling, the system MUST also take into account any other		3.7.1. Client Enforcement
	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 security label accessing the object,
	rather than the security label which opened it, if different.
	The client MUST apply its own policy to remotely located objects,		The client MUST apply its own policy to remotely located objects,
	using security labels for the objects obtained from the server. It		using security labels for the objects obtained from the server. It
	MUST be possible to configure the maximum length of time a client may		MUST be possible to configure the maximum length of time a client may
	cache state regarding remote labels before re-validating that state		cache state regarding remote labels before re-validating that state
	with the server.		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		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 back to the server. The server MUST ensure that any flushed
	state received is consistent with current policy before committing it		state received is consistent with current policy before committing it
	to stable storage.		to stable storage.
	Any local security state associated with cached or delegated objects		Any local security state associated with cached or delegated objects
	MUST also be flushed back to the server when any other state of the		MUST also be flushed back to the server when any other state of the
	objects is required to be flushed back.		objects is required to be flushed back.
	3.7.2. Guest Mode		The implication here is that if the client holds a delegation on an
			object, then it enforces policy to local changes based on the object
			label it got from the server. When it tries to commit those changes
			to the server, it SHOULD be prepared for the server to reject those
			changes based on the policies of the server.
	If the server is MAC-Functional and the client is not, the server		3.7.2. Server Enforcement
	MUST not accept security labels provided by the client, and only
	enforce its policy to exported objects. In the event that the client		A MAC-Functional server MUST enforce its security policy over all
	is MAC-Functional while the server is not then the client may deny		exported objects, for operations which originate both locally and
	access or fall back on other methods for providing security labeling.		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 system 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 security label accessing the object,
			rather than the security label which opened it, if different.
			The server SHOULD recall delegation of an object if the object's
			security label changes.
	3.8. Namespace Access		3.8. Namespace Access
	The server SHOULD provide a means to authorize selective access to		The server SHOULD provide a means to authorize selective access to
	the exported file system namespace based upon client credentials and		the exported file system namespace based upon client credentials and
	according to security policy.		according to security policy.
	This is a common requirement of MLS-enabled systems, which often need		This is a common requirement of MLS-enabled systems, which often need
	to present selective views of namespaces based upon the clearances of		to present selective views of namespaces based upon the clearances of
	the subjects.		the subjects.
	3.9. Upgrading Existing Server		3.9. Upgrading Existing Server
	Note that under the MAC model, all objects MUST have labels.		Note that under the MAC model, all objects MUST have labels.
	Therefore, if an existing server is upgraded to include LNFS support,		Therefore, if an existing server is upgraded to include Labeled NFS
	then it is the responsibility of the security system to define the		support, then it is the responsibility of the security system to
	behavior for existing objects.		define the behavior for existing objects.
	4. Use Cases		4. Use Cases
	MAC labeling is meant to allow NFSv4.2 to be deployed in site		MAC labeling is meant to allow NFSv4.2 to be deployed in site
	configurable security schemes. The LFS and opaque data scheme allows		configurable security schemes. The LFS and opaque data scheme allows
	for flexibility to meet these different implementations. In this		for flexibility to meet these different implementations. In this
	section, we provide some examples of how NFSv4.2 could be deployed to		section, we provide some examples of how NFSv4.2 could be deployed to
	meet existing needs. This is not an exhaustive listing.		meet existing needs. This is not an exhaustive listing.
	4.1. Full MAC labeling support for remotely mounted filesystems		4.1. Full MAC labeling support for remotely mounted filesystems
	skipping to change at page 14, line 14		skipping to change at page 14, line 17
	information sensitivity (e.g., to disclosure) and information		information sensitivity (e.g., to disclosure) and information
	criticality (e.g., to continued business operations) need to be		criticality (e.g., to continued business operations) need to be
	captured.		captured.
	4.5. Simple security label storage		4.5. Simple security label storage
	In this case, a mixed and loosely administered network is assumed,		In this case, a mixed and loosely administered network is assumed,
	where nodes may be running a variety of operating systems with		where nodes may be running a variety of operating systems with
	different security mechanisms and security policies. It is desired		different security mechanisms and security policies. It is desired
	that network file servers be simply capable of storing and retrieving		that network file servers be simply capable of storing and retrieving
	MAC security labels for clients which use such labels. The LNFS		MAC security labels for clients which use such labels. The Labeled
	protocol would be implemented here solely to enable transport of MAC		NFS protocol would be implemented here solely to enable transport of
	security labels across the network. It should be noted that in such		MAC security labels across the network. It should be noted that in
	an environment, overall security cannot be as strongly enforced as		such an environment, overall security cannot be as strongly enforced
	when the server is also enforcing, and that this scheme is aimed at		as when the server is also enforcing, and that this scheme is aimed
	allowing MAC-capable clients to function with its MAC security policy		at allowing MAC-capable clients to function with its MAC security
	enabled rather than perhaps disabling it entirely.		policy enabled rather than perhaps disabling it entirely.
	4.6. Diskless Linux		4.6. Diskless Linux
	A number of popular operating system distributions depend on a		A number of popular operating system distributions depend on a
	mandatory access control (MAC) model to implement a kernel-enforced		mandatory access control (MAC) model to implement a kernel-enforced
	security policy. Typically, such models assign particular roles to		security policy. Typically, such models assign particular roles to
	individual processes, which limit or permit performing certain		individual processes, which limit or permit performing certain
	operations on a set of files, directories, sockets, or other objects.		operations on a set of files, directories, sockets, or other objects.
	While the enforcing of the policy is typically a matter for the		While the enforcing of the policy is typically a matter for the
	diskless NFS client itself, the filesystem objects in such models		diskless NFS client itself, the filesystem objects in such models
	skipping to change at page 17, line 12		skipping to change at page 17, line 14
	client. Assume that the server is using the same criteria used in		client. Assume that the server is using the same criteria used in
	the first example. The server sees the request as coming from a		the first example. The server sees the request as coming from a
	subnet that is a Secret network. The server determines that all		subnet that is a Secret network. The server determines that all
	clients on that subnet will have their requests labeled with Secret.		clients on that subnet will have their requests labeled with Secret.
	Since the directory on the server is labeled Top Secret and Secret		Since the directory on the server is labeled Top Secret and Secret
	does not dominate Top Secret the server would fail the request with		does not dominate Top Secret the server would fail the request with
	NFS4ERR_ACCESS.		NFS4ERR_ACCESS.
	5. Security Considerations		5. Security Considerations
	5.1. Guest Modes		5.1. Trust Needed for a Community
			Labeled NFS is a transport mechanism for labels, a storage
			requirement for labels, and a definition of how to interpret labels.
			It defines the responsibilities of the client and the server in the
			various permutations of being MAC-Functional. It does not however
			dictate in any manner whether assumptions can be made about other
			entities in the relationship. For example, it does not define
			whether a MAC-Functional client can demand that a MAC-Aware server
			only accept requests from other MAC-Functional clients. That is a
			policy based in a MAC model and this document does not impose
			policies on systems.
			As the requirement is a policy, it can be met with the use of a MAC
			model. Let L be a LFS which implements the Limited Server mode,
			i.e., a MAC-Aware server connected to MAC-Functional clients. Then a
			new LFS L' can be created which has the additional policy that the
			MAC-Aware server MUST not accept any requests from a non-MAC-
			Functional client.
			5.2. Guest Modes
	When either the client or server is operating in guest mode it is		When either the client or server is operating in guest mode it is
	important to realize that one side is not enforcing MAC protections.		important to realize that one side is not enforcing MAC protections.
	Alternate methods are being used to handle the lack of MAC support		Alternate methods are being used to handle the lack of MAC support
	and care should be taken to identify and mitigate threats from		and care should be taken to identify and mitigate threats from
	possible tampering outside of these methods.		possible tampering outside of these methods.
	5.2. MAC-Functional Client Configuration		5.3. MAC-Functional Client Configuration
	We defined a MAC model as a access control decision made on a system		We defined a MAC model as a access control decision made on a system
	which normal users do not have the ability to override policies (see		which normal users do not have the ability to override policies (see
	Section 1). If the process labels are created solely on the client,		Section 1). If the process labels are created solely on the client,
	then if a malicious user has sufficient access on that client, the		then if a malicious user has sufficient access on that client, the
	LNFS model is compromised. Note that this is no different from:		Labeled NFS model is compromised. Note that this is no different
			from:
	o current implementations in which the server uses policies to		o current implementations in which the server uses policies to
	effectively determine the object label for requests from the		effectively determine the object label for requests from the
	client, or		client, or
	o local decisions made on the client by the MAC security system.		o local decisions made on the client by the MAC security system.
	The server must either explicitly trust the client (as in [7]) or the		The server must either explicitly trust the client (as in [7]) or the
	MAC model should enforce that users cannot override policies, perhaps		MAC model should enforce that users cannot override policies, perhaps
	via a externally managed source.		via a externally managed source.
	skipping to change at page 18, line 36		skipping to change at page 19, line 11
	[6] Smalley, S., "The Distributed Trusted Operating System (DTOS)		[6] Smalley, S., "The Distributed Trusted Operating System (DTOS)
	Home Page",		Home Page",
	<http://www.cs.utah.edu/flux/fluke/html/dtos/HTML/dtos.html>.		<http://www.cs.utah.edu/flux/fluke/html/dtos/HTML/dtos.html>.
	[7] Carter, J., "Implementing SELinux Support for NFS",		[7] Carter, J., "Implementing SELinux Support for NFS",
	<http://www.nsa.gov/research/_files/selinux/papers/nfsv3.pdf>.		<http://www.nsa.gov/research/_files/selinux/papers/nfsv3.pdf>.
	Appendix A. Acknowledgments		Appendix A. Acknowledgments
	David Quigley was the early energy in motivating the entire LNFS		David Quigley was the early energy in motivating the entire Labeled
	effort.		NFS effort.
	James Morris, Jarrett Lu, and Stephen Smalley all were key		James Morris, Jarrett Lu, and Stephen Smalley all were key
	contributors to both early versions of this document and to many		contributors to both early versions of this document and to many
	conference calls.		conference calls.
	Kathleen Moriarty provided the use cases for ITAR and Legal Hold/		Kathleen Moriarty provided the use cases for ITAR and Legal Hold/
	eDiscovery.		eDiscovery.
	Dan Walsh provided use cases for Secure Virtualization, Sandboxing,		Dan Walsh provided use cases for Secure Virtualization, Sandboxing,
	and NFS homedir labeling to handle process separation.		and NFS homedir labeling to handle process separation.
End of changes. 31 change blocks.
	85 lines changed or deleted		112 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/