Internet Engineering Task Force (IETF) T. Haynes
Request for Comments: 7204 NetApp
Category: Informational April 2014
ISSN: 2070-1721
Internet Engineering Task Force (IETF) T. Haynes
Request for Comments: 7204 NetApp
Category: Informational April 2014
ISSN: 2070-1721
Requirements for Labeled NFS
标记NFS的要求
Abstract
摘要
This memo outlines high-level requirements for the integration of flexible Mandatory Access Control (MAC) functionality into the Network File System (NFS) version 4.2 (NFSv4.2). It describes the level of protections that should be provided over protocol components and the basic structure of the proposed system. The intent here is not to present the protocol changes but to describe the environment in which they reside.
本备忘录概述了将灵活的强制访问控制（MAC）功能集成到网络文件系统（NFS）4.2版（NFSv4.2）中的高级要求。它描述了应通过协议组件提供的保护级别以及拟议系统的基本结构。这里的目的不是展示协议更改，而是描述它们所在的环境。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7204.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7204.
Copyright Notice
版权公告
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2014 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................3
2. Definitions .....................................................3
2.1. Requirements Language ......................................4
3. Requirements ....................................................4
3.1. General ....................................................4
3.2. Security Services ..........................................5
3.3. Label Encoding, Label Format Specifiers, and Label
Checking Authorities .......................................5
3.4. Labeling ...................................................6
3.4.1. Client Labeling .....................................6
3.4.2. Server Labeling .....................................7
3.5. Policy Enforcement .........................................7
3.5.1. Client Enforcement ..................................7
3.5.2. Server Enforcement ..................................8
3.6. Namespace Access ...........................................8
3.7. Upgrading Existing Server ..................................9
4. Modes of Operation ..............................................9
4.1. Full Mode ..................................................9
4.2. Limited Server Mode .......................................10
4.3. Guest Mode ................................................10
5. Use Cases ......................................................11
5.1. Full MAC Labeling Support for Remotely Mounted
File Systems ..............................................11
5.2. MAC Labeling of Virtual Machine Images Stored on
the Network ...............................................11
5.3. Simple Security Label Storage .............................12
5.4. Diskless Linux ............................................12
5.5. Multi-Level Security ......................................13
5.5.1. Full Mode - MAC-Functional Client and Server .......13
5.5.2. MAC-Functional Client ..............................14
5.5.3. MAC-Functional Server ..............................15
6. Security Considerations ........................................15
6.1. Trust Needed for a Community ..............................15
6.2. Guest Mode ................................................15
6.3. MAC-Functional Client Configuration .......................16
7. References .....................................................16
7.1. Normative References ......................................16
7.2. Informative References ....................................16
Appendix A. Acknowledgments .......................................18
1. Introduction ....................................................3
2. Definitions .....................................................3
2.1. Requirements Language ......................................4
3. Requirements ....................................................4
3.1. General ....................................................4
3.2. Security Services ..........................................5
3.3. Label Encoding, Label Format Specifiers, and Label
Checking Authorities .......................................5
3.4. Labeling ...................................................6
3.4.1. Client Labeling .....................................6
3.4.2. Server Labeling .....................................7
3.5. Policy Enforcement .........................................7
3.5.1. Client Enforcement ..................................7
3.5.2. Server Enforcement ..................................8
3.6. Namespace Access ...........................................8
3.7. Upgrading Existing Server ..................................9
4. Modes of Operation ..............................................9
4.1. Full Mode ..................................................9
4.2. Limited Server Mode .......................................10
4.3. Guest Mode ................................................10
5. Use Cases ......................................................11
5.1. Full MAC Labeling Support for Remotely Mounted
File Systems ..............................................11
5.2. MAC Labeling of Virtual Machine Images Stored on
the Network ...............................................11
5.3. Simple Security Label Storage .............................12
5.4. Diskless Linux ............................................12
5.5. Multi-Level Security ......................................13
5.5.1. Full Mode - MAC-Functional Client and Server .......13
5.5.2. MAC-Functional Client ..............................14
5.5.3. MAC-Functional Server ..............................15
6. Security Considerations ........................................15
6.1. Trust Needed for a Community ..............................15
6.2. Guest Mode ................................................15
6.3. MAC-Functional Client Configuration .......................16
7. References .....................................................16
7.1. Normative References ......................................16
7.2. Informative References ....................................16
Appendix A. Acknowledgments .......................................18
Mandatory Access Control (MAC) systems (as defined in [RFC4949]) have been mainstreamed in modern operating systems such as Linux, FreeBSD, and Solaris. MAC systems bind security attributes to subjects (processes) and objects within a system. These attributes are used with other information in the system to make access control decisions.
强制性访问控制（MAC）系统（定义见[RFC4949]）已成为现代操作系统（如Linux、FreeBSD和Solaris）的主流。MAC系统将安全属性绑定到系统中的主题（进程）和对象。这些属性与系统中的其他信息一起用于做出访问控制决策。
Access control models such as Unix permissions or Access Control Lists (ACLs) are commonly referred to as Discretionary Access Control (DAC) models. These systems base their access decisions on user identity and resource ownership. In contrast, MAC models base their access control decisions on the label on the subject (usually a process) and the object it wishes to access. These labels may contain user identity information but usually contain additional information. In DAC systems, users are free to specify the access rules for resources that they own. MAC models base their security decisions on a system-wide policy established by an administrator or organization that the users do not have the ability to override. DAC systems offer some protection against unauthorized users running malicious software. However, even an authorized user can execute malicious or flawed software with those programs running with the full permissions of the user executing it. Inversely, MAC models can confine malicious or flawed software and usually act at a finer granularity than their DAC counterparts.
诸如Unix权限或访问控制列表（ACL）之类的访问控制模型通常称为自主访问控制（DAC）模型。这些系统的访问决策基于用户身份和资源所有权。相比之下，MAC模型的访问控制决策基于主题（通常是进程）和它希望访问的对象的标签。这些标签可能包含用户身份信息，但通常包含附加信息。在DAC系统中，用户可以自由指定其拥有的资源的访问规则。MAC机型的安全决策基于管理员或组织制定的系统范围策略，而用户没有能力覆盖该策略。DAC系统为运行恶意软件的未经授权用户提供了一些保护。但是，即使是授权用户也可以在执行恶意或有缺陷软件的用户拥有完全权限的情况下运行这些程序。相反，MAC模型可以限制恶意或有缺陷的软件，通常比DAC模型的粒度更细。
Besides describing the requirements, this document records the functional requirements for the client imposed by the preexisting security models on the client. This document may help those outside the NFS community understand those issues.
除了描述需求外，本文件还记录了先前存在的安全模型对客户机施加的功能需求。本文档可以帮助NFS社区之外的人理解这些问题。
Foreign Label: a label in a format other than the format that a MAC implementation uses for encoding.
外来标签：一种格式不同于MAC实现用于编码的格式的标签。
Label Format Specifier (LFS): an identifier used by the client to establish the syntactic format of the security label and the semantic meaning of its components.
标签格式说明符（LFS）：客户端用于建立安全标签的语法格式及其组件的语义的标识符。
MAC-Aware: a server that can transmit and store object labels.
MAC感知：可以传输和存储对象标签的服务器。
MAC-Functional: a client or server that is Labeled NFS enabled. Such a system can interpret labels and apply policies based on the security system.
MAC Functional：标记为启用NFS的客户端或服务器。这样的系统可以基于安全系统解释标签和应用策略。
Multi-Level Security (MLS): a traditional model where objects are given a sensitivity level (Unclassified, Secret, Top Secret, etc.) and a category set [RH_MLS].
多级安全（MLS）：一种传统模型，其中对象被赋予一个敏感级别（未分类、机密、绝密等）和一个类别集[RH_MLS]。
Object: a passive resource within the system that we wish to protect. Objects can be entities such as files, directories, pipes, sockets, and many other system resources relevant to the protection of the system state.
对象：系统中我们希望保护的被动资源。对象可以是实体，如文件、目录、管道、套接字和许多其他与系统状态保护相关的系统资源。
Policy Identifier (PI): an optional part of the definition of a Label Format Specifier. The PI allows clients and servers to identify specific security policies.
策略标识符（PI）：标签格式说明符定义的可选部分。PI允许客户端和服务器识别特定的安全策略。
Subject: an active entity, usually a process, that is requesting access to an object.
主题：请求访问对象的活动实体，通常是进程。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
The following initial requirements have been gathered from users and developers, and from previous development efforts in this area such as the Distributed Trusted Operating System [DTOS] and the NSA's experimental NFSv3 enhancements [SENFSv3].
以下初始需求来自用户和开发人员，以及该领域以前的开发工作，如分布式可信操作系统[DTOS]和NSA的实验性NFSv3增强[SENFSv3]。
A mechanism is required to provide security attribute information to NFSv4 clients and servers. This mechanism has the following requirements:
需要一种机制向NFSv4客户端和服务器提供安全属性信息。该机制具有以下要求：
(1) Clients MUST be able to convey to the server the client's privileges, i.e., the subject, for making the access request. The server may provide a mechanism to enforce MAC policy based on the requesting client's privileges.
(1) 客户端必须能够向服务器传递客户端的权限，即发出访问请求的主体。服务器可提供基于请求客户端的权限强制实施MAC策略的机制。
(2) Servers MUST be able to store and retrieve the security attribute of exported files as requested by the client.
(2) 服务器必须能够存储和检索客户端请求的导出文件的安全属性。
(3) Servers MUST provide a mechanism for notifying clients of attribute changes of files on the server.
(3) 服务器必须提供一种机制，用于通知客户端服务器上文件的属性更改。
(4) Clients and Servers MUST be able to negotiate Label Formats and provide a mechanism to translate between them as needed.
(4) 客户机和服务器必须能够协商标签格式，并根据需要提供在它们之间进行转换的机制。
Labeled NFS or the underlying system on which the Labeled NFS operates MUST provide the following security services for all NFSv4.2 messaging:
标记的NFS或标记的NFS运行的基础系统必须为所有NFSv4.2消息传递提供以下安全服务：
o Authentication
o 认证
o Integrity
o 诚实正直
o Privacy
o 隐私
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 is required between the server and the client for Full Mode operation (Section 4.1).
对于全模式操作，服务器和客户端之间需要强大的相互身份验证（第4.1节）。
MAC 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.
MAC安全标签和任何相关安全状态在通过网络传输时必须始终受到这些安全服务的保护，标签和状态与相关对象和主题的绑定也必须受到保护。
Labeled NFS SHOULD support authentication on a context granularity so that different contexts running on a client can use different cryptographic keys and facilities.
带标签的NFS应该支持上下文粒度上的身份验证，以便在客户端上运行的不同上下文可以使用不同的加密密钥和设施。
3.3. Label Encoding, Label Format Specifiers, and Label Checking Authorities
3.3. 标签编码、标签格式说明符和标签检查机构
Encoding of MAC labels and attributes passed over the network MUST be specified in a complete and unambiguous manner while maintaining the flexibility of MAC implementations. To accomplish this, the labels MUST consist of a format-specific component bound with a Label Format Specifier (LFS). The LFS component provides a mechanism for identifying the structure and semantics of the opaque component. Meanwhile, the opaque component is the security label that will be interpreted by the MAC models.
必须以完整和明确的方式指定通过网络传递的MAC标签和属性的编码，同时保持MAC实现的灵活性。要实现这一点，标签必须由特定于格式的组件组成，该组件与标签格式说明符（LFS）绑定。LFS组件提供了一种识别不透明组件的结构和语义的机制。同时，不透明组件是将由MAC模型解释的安全标签。
MAC models base access decisions on security attribute privileges bound to subjects and objects, respectively. With a given MAC model, all systems have semantically coherent labeling -- a security label MUST always mean exactly the same thing on every system. While this may not be necessary for simple MAC models, it is recommended that most Label Formats assigned an LFS incorporate semantically coherent labeling into their Label Format.
MAC模型基于分别绑定到主体和对象的安全属性特权来做出访问决策。对于给定的MAC模型，所有系统都有语义一致的标签——安全标签在每个系统上的含义必须完全相同。虽然这对于简单的MAC模型可能不是必需的，但建议分配给LFS的大多数标签格式将语义一致的标签合并到其标签格式中。
Labeled NFS SHOULD define an initial negotiation scheme with the primary aims of simplicity and completeness. This is to facilitate practical deployment of systems without being weighed down by complex and overgeneralized global schemes. Future extensibility SHOULD also be taken into consideration.
有标签的NFS应该定义一个初始协商方案，其主要目的是简单和完整。这是为了促进系统的实际部署，而不会受到复杂和过度概括的全局方案的影响。还应考虑未来的可扩展性。
Labeled NFS MUST provide a means for servers and clients to identify their LFSs for the purposes of authorization, security service selection, and security label interpretation.
带标签的NFS必须为服务器和客户端提供一种方法来识别其LFS，以便进行授权、安全服务选择和安全标签解释。
Labeled NFS MUST provide a means for servers and clients to identify their mode of operation (see Section 4).
带标签的NFS必须为服务器和客户端提供一种方法来识别其操作模式（请参见第4节）。
A negotiation scheme SHOULD be provided, allowing systems from different Label Formats to agree on how they will interpret or translate each other's foreign labels. Multiple concurrent 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 LFS.
通过网络传输的所有安全标签和相关安全状态必须使用有效的LFS进行标记。
If the LFS supported on a system changes, the system SHOULD renegotiate agreements to reflect these changes.
如果系统支持的LFS发生变化，系统应重新协商协议以反映这些变化。
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 label or state.
如果系统接收到任何带有LFS标记的安全标签或安全状态，它无法识别或解释，则必须拒绝该标签或状态。
NFSv4.2 includes features that may cause a client to cross an LFS boundary when accessing what appears to be a single file system. If LFS negotiation is supported by the client and the server, the server SHOULD negotiate a new, concurrent agreement with the client, acting on behalf of the externally located source of the files.
NFSv4.2包括一些功能，这些功能可能会导致客户端在访问看似单一的文件系统时跨越LFS边界。如果客户端和服务器支持LFS协商，则服务器应代表位于外部的文件源与客户端协商新的并发协议。
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.
实现必须验证通过网络提供的安全标签，以确保它们在特定对等方允许的一组标签内，如果不在，则拒绝它们。请注意，系统可能允许从每个对等方接受不同的标签集。
At the client, labeling semantics for NFS mounted file systems MUST remain consistent with those for locally mounted file systems. In particular, user-level labeling operations local to the client MUST be enacted locally via existing APIs, to ensure compatibility and consistency for applications and libraries.
在客户端，NFS安装的文件系统的标签语义必须与本地安装的文件系统的标签语义保持一致。特别是，客户端本地的用户级标记操作必须通过现有API在本地执行，以确保应用程序和库的兼容性和一致性。
Note that this does not imply any specific mechanism for conveying labels over the network.
注意，这并不意味着通过网络传送标签的任何特定机制。
When an object is newly created by the client, it will calculate the label for the object based on its policy. Once that is done, it will send the request to the server, which has the ability to deny the creation of the object with that label based on the server's policy. In creating the file, the server MUST ensure that the label is 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.
当客户端新创建对象时，它将根据其策略计算对象的标签。完成后，它将向服务器发送请求，服务器能够根据服务器的策略拒绝创建带有该标签的对象。在创建文件时，服务器必须确保在对象对系统其余部分可见之前将标签绑定到该对象。这可确保任何访问控制或进一步的标记决策都适用于对象。
The server MUST provide the capability for clients to retrieve security labels on all exported file system 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 file systems.
在可能的情况下，服务器必须为客户端提供检索所有导出文件系统对象上的安全标签的功能。这包括以下情况：对于任何导出的文件系统，服务器上只能使用内核和/或只读安全标签。
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 to reject the label specified by the client, due to restrictions in the server policy. The server SHOULD NOT attempt to find a suitable label for an object in the event of different labeling rules on its end. The server is allowed to translate the label but MUST NOT change the semantic meaning of the label.
服务器必须尊重客户端在创建对象时指定对象标签的能力。如果服务器已启用MAC，则由于服务器策略中的限制，它可能会选择拒绝客户端指定的标签。如果对象端部有不同的标签规则，服务器不应尝试为对象找到合适的标签。允许服务器翻译标签，但不得更改标签的语义。
The MAC-Functional client determines if a process request is sent to the remote server. Upon a successful response from the server, it must use its own policies on the object's security labels to determine if the process can be given access. The client SHOULD NOT need to be cognizant of whether the server is a Limited Server or is fully MAC-Functional.
MAC功能客户端确定是否向远程服务器发送进程请求。服务器成功响应后，它必须在对象的安全标签上使用自己的策略来确定是否可以授予进程访问权限。客户机不需要知道服务器是有限的服务器还是完全具有MAC功能。
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.
客户端必须使用从服务器获取的对象的安全标签，将其自己的策略应用于远程定位的对象。在使用服务器重新验证远程标签的状态之前，必须能够配置客户端缓存该状态的最长时间。
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.
当需要回冲对象的任何其他状态时，与缓存或委托对象关联的任何本地安全状态也必须回冲到服务器。
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.
这里的含义是，如果客户机持有对对象的委托，那么它将根据从服务器获得的对象标签对本地更改强制执行策略。当它尝试将这些更改提交给服务器时，应该准备好让服务器根据服务器的策略拒绝这些更改。
A MAC-Functional server MUST enforce its security policy over all exported objects, for operations that originate both locally and remotely.
对于本地和远程发起的操作，MAC功能服务器必须对所有导出的对象强制执行其安全策略。
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 that opened it, if different.
与标记一样，系统还必须考虑任何其他易失性客户端安全状态，例如通过动态转换在流程安全上下文中进行的更改。访问决策还应基于访问对象的当前客户端安全标签，而不是打开对象的安全标签（如果不同的话）。
The server SHOULD recall delegation of an object if the object's security label changes.
如果对象的安全标签更改，服务器应该调用对象的委派。
The server SHOULD provide a means to authorize selective access to the exported file system 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.
这是支持MLS的系统的一个常见需求，通常需要根据主题的许可来呈现名称空间的选择性视图。
Note that under the MAC model, all objects MUST have labels. Therefore, if an existing server is upgraded to include Labeled NFS support, then it is the responsibility of the security system to define the behavior for existing objects.
请注意，在MAC模型下，所有对象都必须有标签。因此，如果现有服务器升级为包含标记的NFS支持，则安全系统负责定义现有对象的行为。
In a Labeled NFS client and server interaction, we can describe three modes of operation:
在标记的NFS客户端和服务器交互中，我们可以描述三种操作模式：
1. Full
1. 满的
2. Limited Server
2. 有限服务器
3. Guest
3. 客人
These modes arise from the level of MAC functionality in the clients and servers. The clients can be non-MAC-Functional and MAC-Functional. The servers can be non-MAC-Functional, MAC-Aware, and MAC-Functional.
这些模式产生于客户端和服务器的MAC功能级别。客户端可以是非MAC功能的，也可以是MAC功能的。服务器可以是非MAC功能、MAC感知和MAC功能。
A MAC-Functional client MUST be able to determine the level of MAC functionality in the server. Likewise, a MAC-Functional server MUST be able to determine whether or not a client is MAC-Functional. As discussed in Section 3.3, the protocol MUST provide for the client and server to make those determinations.
MAC功能客户端必须能够确定服务器中MAC功能的级别。同样，MAC功能服务器必须能够确定客户端是否具有MAC功能。如第3.3节所述，协议必须为客户机和服务器提供这些确定。
The server and the client have mutually recognized MAC functionality enabled, and full Labeled NFS functionality is extended over the network between both client and server.
服务器和客户端启用了相互认可的MAC功能，并且在客户端和服务器之间的网络上扩展了完整的带标签的NFS功能。
An example of an operation in Full Mode is as follows. On the initial lookup, the client requests access to an object on the server. It sends its process security context over to the server. The server checks all relevant policies to determine if that process context from that client is allowed to access the resource. Once this has succeeded, the object, with its associated security information, is released to the client. Once the client receives the object, it determines if its policies allow the process running on the client access to the object.
全模式下的操作示例如下所示。在初始查找时，客户端请求访问服务器上的对象。它将其进程安全上下文发送到服务器。服务器检查所有相关策略，以确定是否允许来自该客户端的流程上下文访问资源。一旦成功，对象及其关联的安全信息将被释放到客户端。一旦客户机接收到该对象，它将确定其策略是否允许在客户机上运行的进程访问该对象。
On subsequent operations where the client already has a handle for the file, the order of enforcement is reversed. Since the client already has the security context, it may make an access decision against its policy first. This enables the client to avoid sending requests to the server that it knows will fail, regardless of the server's policy. If the client passes its policy checks, then it sends the request to the server, where the client's process context is used to determine if the server will release that resource to the client. If both checks pass, the client is given the resource and everything succeeds.
在客户端已经拥有文件句柄的后续操作中，强制执行的顺序是相反的。由于客户端已经具有安全上下文，它可能会首先根据其策略做出访问决策。这使客户机能够避免向它知道将失败的服务器发送请求，而不管服务器的策略如何。如果客户机通过了策略检查，那么它会将请求发送到服务器，在服务器上，客户机的流程上下文用于确定服务器是否会将该资源释放给客户机。如果两个检查都通过，那么客户端将获得资源，并且所有操作都会成功。
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 ability to return security information.
如果客户端不信任服务器，它可能会选择使用备用标记机制，而不管服务器是否能够返回安全信息。
The server is MAC-Aware, and the clients are MAC-Functional. The server can store and transmit labels. It cannot enforce labels. The server MUST inform clients when an object label changes for a file the client has open.
服务器支持MAC，客户端支持MAC功能。服务器可以存储和传输标签。它不能强制执行标签。当客户端打开的文件的对象标签发生更改时，服务器必须通知客户端。
In this mode, the server may not be aware of the format of any of its object labels. Indeed, it may service several different security models at the same time. A client MUST process foreign labels as discussed in Section 3.3. As with the Guest Mode, this mode's level of trust can be degraded if non-MAC-Functional clients have access to the server.
在此模式下，服务器可能不知道其任何对象标签的格式。事实上，它可能同时服务于多个不同的安全模型。客户必须按照第3.3节所述处理外来标签。与来宾模式一样，如果非MAC功能客户端可以访问服务器，则此模式的信任级别可能会降低。
Only one of the server or client is MAC-Functional enabled.
只有一个服务器或客户端启用了MAC功能。
In the case of the server only being MAC-Functional, the server 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.
在服务器仅具有MAC功能的情况下，服务器实施其策略，并且可以根据安全策略基于客户端的认证凭证和/或相关网络属性（例如，IP地址、网络接口）选择性地向客户端提供标准NFS服务。在此模式下扩展到客户端的信任和访问级别是特定于配置的。
In the case of the client only being MAC-Functional, the client MUST operate as a standard NFSv4.2 (see [NFSv4_2]) client and SHOULD selectively provide processes access to servers based upon the security attributes of the local process, and network attributes of the server, according to policy. The client may also override default labeling of the remote file system based upon these security attributes or other labeling methods such as mount point labeling.
如果客户机仅具有MAC功能，则客户机必须作为标准NFSv4.2（参见[NFSv4_2]）客户机运行，并应根据策略，根据本地进程的安全属性和服务器的网络属性有选择地向服务器提供进程访问。客户端还可以基于这些安全属性或其他标记方法（如装入点标记），覆盖远程文件系统的默认标记。
In other words, the Guest Mode is standard NFSv4.2 over the wire, with the MAC-Functional system mapping the non-MAC-Functional system's processes or objects to security labels based on other characteristics in order to preserve its MAC guarantees.
换句话说，来宾模式是标准的NFSv4.2无线传输模式，MAC功能系统基于其他特征将非MAC功能系统的进程或对象映射到安全标签，以保留其MAC保证。
MAC labeling is meant to allow NFSv4.2 to be deployed in site-configurable security schemes. The LFS and opaque data scheme allows for flexibility to meet these different implementations. In this section, we provide some examples of how NFSv4.2 could be deployed to meet existing needs. This is not an exhaustive listing.
MAC标签旨在允许在站点可配置的安全方案中部署NFSv4.2。LFS和不透明数据方案允许灵活地满足这些不同的实现。在本节中，我们将提供一些示例，说明如何部署NFSv4.2以满足现有需求。这不是一个详尽的清单。
In this case, we assume a local networked environment where the servers and clients are under common administrative control. All systems in this network have the same MAC implementation and semantically identical MAC security labels for objects (i.e., labels mean the same thing on different systems, even if the policies on each system may differ to some extent). Clients will be able to apply fine-grained MAC policy to objects accessed via NFS mounts and thus improve the overall consistency of MAC policy application within this environment.
在这种情况下，我们假设一个本地网络环境，其中服务器和客户端处于公共管理控制之下。该网络中的所有系统都具有相同的MAC实现和对象的语义相同的MAC安全标签（即，标签在不同系统上表示相同的内容，即使每个系统上的策略可能在某种程度上有所不同）。客户端将能够对通过NFS装载访问的对象应用细粒度MAC策略，从而提高此环境中MAC策略应用程序的总体一致性。
An example of this case would be where user home directories are remotely mounted, and fine-grained MAC policy is implemented to protect, for example, private user data from being read by malicious web scripts running in the user's browser. With Labeled NFS, fine-grained MAC labeling of the user's files will allow the MAC policy to be implemented and provide the desired protection.
这种情况的一个示例是远程装载用户主目录，并实施细粒度MAC策略以保护（例如）私人用户数据不被用户浏览器中运行的恶意web脚本读取。使用带标签的NFS，用户文件的细粒度MAC标签将允许实现MAC策略并提供所需的保护。
Virtualization is now a commonly implemented feature of modern operating systems, and there is a need to ensure that MAC security policy is able to protect virtualized resources. A common implementation scheme involves storing virtualized guest file systems on a networked server; these file systems are then mounted remotely by guests upon instantiation. In this case, there is a need to ensure that the local guest kernel is able to access fine-grained MAC labels on the remotely mounted file system so that its MAC security policy can be applied.
虚拟化现在是现代操作系统的一个常用功能，需要确保MAC安全策略能够保护虚拟化资源。一种常见的实现方案涉及在网络服务器上存储虚拟化来宾文件系统；然后，来宾在实例化时远程装载这些文件系统。在这种情况下，需要确保本地来宾内核能够访问远程装载的文件系统上的细粒度MAC标签，以便应用其MAC安全策略。
In this case, a mixed and loosely administered network is assumed, where nodes may be running a variety of operating systems with different security mechanisms and security policies. It is desired that network file servers be simply capable of storing and retrieving MAC security labels for clients that use such labels. The Labeled NFS protocol would be implemented here solely to enable transport of MAC security labels across the network. It should be noted that in such an environment, overall security cannot be as strongly enforced as when the server is also enforcing and that this scheme is aimed at allowing MAC-capable clients to function with its MAC security policy enabled rather than perhaps disabling it entirely.
在这种情况下，假设存在一个混合且管理松散的网络，其中节点可能运行具有不同安全机制和安全策略的各种操作系统。希望网络文件服务器能够简单地为使用MAC安全标签的客户端存储和检索MAC安全标签。这里实现的带标签的NFS协议仅用于在网络上传输MAC安全标签。应该注意的是，在这样的环境中，整体安全性不能像服务器也在强制执行时那样强制执行，并且该方案旨在允许支持MAC的客户端在启用其MAC安全策略的情况下运行，而不是可能完全禁用它。
A number of popular operating system distributions depend on a Mandatory Access Control (MAC) model to implement a kernel-enforced security policy. Typically, such models assign particular roles to individual processes, which limit or permit performing certain operations on a set of files, directories, sockets, or other objects. While the enforcing of the policy is typically a matter for the diskless NFS client itself, the file system objects in such models will typically carry MAC labels that are used to define policy on access. These policies may, for instance, describe privilege transitions that cannot be replicated using standard NFS ACL-based models.
许多流行的操作系统发行版依赖于强制访问控制（MAC）模型来实现内核强制的安全策略。通常，此类模型将特定角色分配给单个进程，从而限制或允许对一组文件、目录、套接字或其他对象执行某些操作。虽然强制执行策略通常是无盘NFS客户机本身的事情，但此类模型中的文件系统对象通常带有MAC标签，用于定义访问策略。例如，这些策略可能描述无法使用基于标准NFS ACL的模型复制的权限转换。
For instance, on a SYSV-compatible system (see [SYSV]), if the 'init' process spawns a process that attempts to start the 'NetworkManager' executable, there may be a policy that sets up a role transition if the 'init' process and 'NetworkManager' file labels match a particular rule. Without this role transition, the process may find itself having insufficient privileges to perform its primary job of configuring network interfaces.
例如，在与SYSV兼容的系统（请参见[SYSV]）上，如果“init”进程生成一个试图启动“NetworkManager”可执行文件的进程，则如果“init”进程和“NetworkManager”文件标签匹配特定规则，则可能存在一个设置角色转换的策略。如果没有此角色转换，进程可能会发现自己没有足够的权限来执行其配置网络接口的主要工作。
In setups of this type, a lot of the policy targets (such as sockets or privileged system calls) are entirely local to the client. The use of RPCSEC_GSSv3 ([RPC_SEC]) for enforcing compliance at the server level is therefore of limited value. The ability to permanently label files and have those labels read back by the client is, however, crucial to the ability to enforce that policy.
在这种类型的设置中，许多策略目标（例如套接字或特权系统调用）都是客户端的本地目标。因此，使用RPCSEC_GSSv3（[RPC_SEC]）在服务器级别强制执行法规遵从性的价值有限。但是，永久标记文件并让客户端读回这些标签的能力对于强制执行该策略的能力至关重要。
In an MLS system, objects are generally assigned a sensitivity level and a set of compartments. The sensitivity levels within the system are given an order ranging from lowest to highest classification level. Read access to an object is allowed when the sensitivity level of the subject "dominates" the object it wants to access. This means that the sensitivity level of the subject is higher than that of the object it wishes to access and that its set of compartments is a superset of the compartments on the object.
在MLS系统中，通常为对象分配一个灵敏度级别和一组隔室。系统内的灵敏度等级从最低分类等级到最高分类等级。当主体的敏感度水平“支配”其想要访问的对象时，允许对对象进行读取访问。这意味着主体的敏感度水平高于其希望访问的对象的敏感度水平，并且其隔室集是对象上隔室的超集。
The rest of this section will just use sensitivity levels. In general, the example is a client that wishes to list the contents of a directory. The system defines the sensitivity levels as Unclassified (U), Secret (S), and Top Secret (TS). The directory to be searched is labeled Top Secret, which means access to read the directory will only be granted if the subject making the request is also labeled Top Secret.
本节的其余部分将仅使用灵敏度级别。通常，示例是希望列出目录内容的客户机。系统将灵敏度级别定义为未分类（U）、机密（S）和绝密（TS）。要搜索的目录被标记为Top Secret，这意味着只有在发出请求的主题也被标记为Top Secret时，才能授予读取目录的权限。
In the first part of this example, a process on the client is running at the Secret level. The process issues a readdir() system call, which enters the kernel. Before translating the readdir() system call into a request to the NFSv4.2 server, the host operating system will consult the MAC module to see if the operation is allowed. Since the process is operating at Secret and the directory to be accessed is labeled Top Secret, the MAC module will deny the request and an error code is returned to user space.
在本例的第一部分中，客户机上的进程以机密级别运行。进程发出readdir（）系统调用，该调用进入内核。在将readdir（）系统调用转换为对NFSv4.2服务器的请求之前，主机操作系统将咨询MAC模块，查看是否允许该操作。由于进程以机密方式运行，并且要访问的目录被标记为绝密，因此MAC模块将拒绝该请求，并向用户空间返回一个错误代码。
Consider a second case where instead of running at Secret the process is running at Top Secret. In this case, the sensitivity of the process is equal to or greater than that of the directory, so the MAC module will allow the request. Now the readdir() is translated into the necessary NFSv4.2 call to the server. For the remote procedure call (RPC) request, the client is using the proper credential to assert to the server that the process is running at Top Secret.
考虑第二种情况，而不是秘密运行，进程运行在最高机密。在这种情况下，进程的敏感度等于或大于目录的敏感度，因此MAC模块将允许请求。现在readdir（）被转换为对服务器的必要NFSv4.2调用。对于远程过程调用（RPC）请求，客户端正在使用正确的凭据向服务器断言进程正在以绝密方式运行。
When the server receives the request, it extracts the security label from the RPC session and retrieves the label on the directory. The server then checks with its MAC module to see if a Top Secret process is allowed to read the contents of the Top Secret directory. Since this is allowed by the policy, then the server will return the appropriate information back to the client.
当服务器收到请求时，它将从RPC会话提取安全标签，并检索目录上的标签。然后，服务器使用其MAC模块检查是否允许绝密进程读取绝密目录的内容。因为这是策略允许的，所以服务器将把适当的信息返回给客户端。
In this example, the policy on both the client and server is the same. In the event that they were running different policies, a translation of the labels might be needed. In this case, it could be possible for a check to pass on the client and fail on the server. The server may consider additional information when making its policy decisions. For example, the server could determine that a certain subnet is only cleared for data up to Secret classification. If that constraint was in place for the example above, the client would still succeed, but the server would fail, since the client is asserting a label that it is not able to use (Top Secret on a Secret network).
在本例中，客户端和服务器上的策略是相同的。如果它们运行不同的策略，则可能需要对标签进行翻译。在这种情况下，检查可能在客户机上通过，而在服务器上失败。服务器在作出策略决策时可以考虑其他信息。例如，服务器可以确定某个子网仅为机密分类的数据清除。如果在上面的示例中设置了该约束，则客户端仍将成功，但服务器将失败，因为客户端正在声明一个它无法使用的标签（机密网络上的绝密）。
In these scenarios, the server is either non-MAC-Aware or MAC-Aware. The actions of the client will depend on whether it is configured to treat the MAC-Aware server in the same manner as the non-MAC-Aware one. That is, does it utilize the approach presented in Section 4.3, or does it allow the MAC-Aware server to return labels?
在这些场景中，服务器要么不支持MAC，要么支持MAC。客户端的操作将取决于它是否配置为以与非MAC感知服务器相同的方式处理MAC感知服务器。也就是说，它是利用第4.3节中介绍的方法，还是允许MAC感知服务器返回标签？
With a client that is MAC-Functional and using the example in the previous section, the result should be the same. The one difference is that all decisions are made on the client.
对于具有MAC功能的客户端，使用上一节中的示例，结果应该是相同的。唯一的区别是所有的决定都是由客户做出的。
A process on the client labeled Secret wishes to access a directory labeled Top Secret on the server. This is denied, since Secret does not dominate Top Secret. Note that there will be NFSv4.2 operations issued that return an object label for the client to process.
客户端上标记为Secret的进程希望访问服务器上标记为Top Secret的目录。这一点被否认了，因为机密并不是最高机密。请注意，将发布NFSv4.2操作，返回对象标签供客户端处理。
Note that in this scenario, all of the clients must be MAC-Functional. A single client that does not do its access control checks would violate the model.
请注意，在此场景中，所有客户端都必须具有MAC功能。不进行访问控制检查的单个客户端将违反该模型。
A process on the client labeled Secret wishes to access a directory that the client's policies label as Top Secret on the server. This is denied, since Secret does not dominate Top Secret. Note that there will not be NFSv4.2 operations issued. If the process had a Top Secret process label instead of Secret, the client would issue NFSv4.2 operations to access the directory on the server.
客户端上标记为机密的进程希望访问服务器上客户端策略标记为绝密的目录。这一点被否认了，因为机密并不是最高机密。请注意，不会发布NFSv4.2操作。如果进程具有绝密进程标签而不是机密，则客户端将发出NFSv4.2操作以访问服务器上的目录。
With a MAC-Functional server and a client that is not, the client behaves as if it were in a normal NFSv4.2 environment. Since the process on the client does not provide a security attribute, the server must define a mechanism for labeling all requests from a client. Assume that the server is using the same criteria used in the first example. The server sees the request as coming from a subnet that is a Secret network. The server determines that all clients on that subnet will have their requests labeled with 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 NFS4ERR_ACCESS.
对于MAC功能服务器和非功能服务器的客户机，客户机的行为就像在正常的NFSv4.2环境中一样。由于客户端上的进程不提供安全属性，服务器必须定义一种机制来标记来自客户端的所有请求。假设服务器使用的标准与第一个示例中使用的标准相同。服务器认为请求来自一个子网，该子网是一个秘密网络。服务器确定该子网上的所有客户端的请求都将标记为机密。由于服务器上的目录被标记为Top Secret，并且Secret不占Top Secret的主导地位，因此服务器将使用NFS4ERR_访问失败请求。
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 on a MAC model, and this document does not impose policies on systems.
带标签的NFS是标签的传输机制、标签的存储要求以及如何解释标签的定义。它定义了客户机和服务器在MAC功能的各种排列中的责任。然而，它并不以任何方式规定是否可以对关系中的其他实体进行假设。例如，它没有定义MAC功能客户端是否可以要求MAC感知服务器只接受来自其他MAC功能客户端的请求。这是一个基于MAC模型的策略，本文档不在系统上强加策略。
As the requirement is a policy, it can be met with the use of a MAC model. Let L be an LFS that implements the Limited Server mode, i.e., a MAC-Aware server connected to MAC-Functional clients. Then a new LFS, L', can be created that has the additional policy that the MAC-Aware server MUST NOT accept any requests from a non-MAC-Functional client.
由于需求是一种策略，因此可以通过使用MAC模型来满足需求。设L为实现受限服务器模式的LFS，即连接到MAC功能客户端的MAC感知服务器。然后，可以创建一个新的LFS，L'，该LFS具有额外的策略，即MAC感知服务器不得接受来自非MAC功能客户端的任何请求。
When either the client or server is operating in Guest Mode, it is important to realize that one side is not enforcing MAC protections. Alternate methods are being used to handle the lack of MAC support, and care should be taken to identify and mitigate threats from possible tampering outside of these methods.
当客户机或服务器在来宾模式下运行时，重要的是要意识到一方没有实施MAC保护。正在使用替代方法来处理缺乏MAC支持的问题，应注意识别并减轻这些方法之外可能的篡改所带来的威胁。
We defined a MAC model as an access control decision made on a system in which normal users do not have the ability to override policies (see Section 1). If the process labels are created solely on the client, then if a malicious user has sufficient access on that client, the Labeled NFS model is compromised. Note that this is no different from:
我们将MAC模型定义为在正常用户无法覆盖策略的系统上做出的访问控制决策（参见第1节）。如果进程标签仅在客户端上创建，那么如果恶意用户在该客户端上具有足够的访问权限，则标记的NFS模型将受到损害。请注意，这与：
o current implementations in which the server uses policies to effectively determine the object label for requests from the client, or
o 服务器使用策略有效确定客户端请求的对象标签的当前实现，或
o local decisions made on the client by the MAC security system.
o MAC安全系统在客户端做出的本地决策。
Either the server must explicitly trust the client (as in [SENFSv3]) or the MAC model should enforce that users cannot override policies, perhaps via an externally managed source.
要么服务器必须明确信任客户机（如[SENFSv3]），要么MAC模型应该强制用户不能覆盖策略，可能是通过外部管理的源。
Once the labels leave the client, they can be protected by the transport mechanism as described in Section 3.2.
标签离开客户机后，可通过第3.2节所述的传输机制进行保护。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[DTOS] Smalley, S., "The Distributed Trusted Operating System (DTOS) Home Page", December 2000, <http://www.cs.utah.edu/ flux/fluke/html/dtos/HTML/dtos.html>.
[DTOS]Smalley，S.，“分布式可信操作系统（DTOS）主页”，2000年12月<http://www.cs.utah.edu/ flux/fluke/html/dtos/html/dtos.html>。
[NFSv4_2] Haynes, T., "NFS Version 4 Minor Version 2", Work in Progress, February 2014.
[NFSv4_2]Haynes，T.，“NFS版本4次要版本2”，正在进行的工作，2014年2月。
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC 4949, August 2007.
[RFC4949]Shirey，R.，“互联网安全术语表，第2版”，RFC 49492007年8月。
[RH_MLS] "Multi-Level Security (MLS)", "Deployment, configuration and administration of Red Hat Enterprise Linux 5, Edition 10", Section 49.6, 2014, <http://docs.redhat.com/docs/ en-US/Red_Hat_Enterprise_Linux/5/html/Deployment_Guide/ sec-mls-ov.html>.
[RH_MLS]“多级安全（MLS）”，“Red Hat Enterprise Linux 5的部署、配置和管理，第10版”，第49.6节，2014年<http://docs.redhat.com/docs/ en US/Red\u Hat\u Enterprise\u Linux/5/html/Deployment\u Guide/sec mls ov.html>。
[RPC_SEC] Adamson, W. and N. Williams, "Remote Procedure Call (RPC) Security Version 3", Work in Progress, February 2014.
[RPC_SEC]Adamson，W.和N.Williams，“远程过程调用（RPC）安全版本3”，正在进行的工作，2014年2月。
[SENFSv3] Carter, J., "Implementing SELinux Support for NFS", <http://www.nsa.gov/research/_files/selinux/papers/ nfsv3.pdf>.
[SENFSv3]Carter，J.，“为NFS实现SELinux支持”<http://www.nsa.gov/research/_files/selinux/papers/ nfsv3.pdf>。
[SYSV] AT&T, "System V Interface Definition (SVID)", Third Edition, Addison-Wesley, Reading, MA, 1989.
[SYSV]AT&T，“系统V接口定义（SVID）”，第三版，Addison-Wesley，雷丁，马萨诸塞州，1989年。
David Quigley was the early energy in motivating the entire Labeled NFS effort.
大卫·奎格利是推动整个努力的早期力量。
James Morris, Jarrett Lu, and Stephen Smalley all were key contributors to both early versions of this document and to many conference calls.
James Morris、Jarrett Lu和Stephen Smalley都是本文档早期版本和许多电话会议的主要贡献者。
Kathleen Moriarty provided use cases for earlier versions of the document.
Kathleen Moriarty为文档的早期版本提供了用例。
Dan Walsh provided use cases for Secure Virtualization, Sandboxing, and NFS homedir labeling to handle process separation.
Dan Walsh提供了安全虚拟化、沙箱和NFS homedir标记的用例，以处理进程分离。
Trond Myklebust provided use cases for secure diskless NFS clients.
Trond Myklebast为安全无盘NFS客户端提供了用例。
Both Nico Williams and Bryce Nordgren challenged assumptions during the review processes.
Nico Williams和Bryce Nordgren在审查过程中都对假设提出了质疑。
Author's Address
作者地址
Thomas Haynes NetApp 495 East Java Dr. Sunnyvale, CA 94089 USA
Thomas Haynes NetApp 495东爪哇桑尼维尔博士，美国加利福尼亚州94089
Phone: +1 408 215 1519
EMail: tdh@excfb.com
Phone: +1 408 215 1519
EMail: tdh@excfb.com