[要約] RFC 7204は、ラベル付きNFSの要件を定義しています。その目的は、セキュリティとアクセス制御の向上を通じて、NFSのセキュアなデータ共有を実現することです。
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.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
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（Internet Engineering Task Force）の製品です。これは、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.
Copyright（c）2014 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
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
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）モデルと呼ばれます。これらのシステムは、ユーザーIDとリソースの所有権に基づいてアクセスを決定します。対照的に、MACモデルは、サブジェクト（通常はプロセス）とアクセスしたいオブジェクトのラベルに基づいてアクセス制御を決定します。これらのラベルにはユーザーID情報が含まれる場合がありますが、通常は追加情報が含まれます。 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機能：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].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [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）クライアントは、アクセス要求を行うためのクライアントの特権、つまりサブジェクトをサーバーに伝達できなければなりません（MUST）。サーバーは、要求しているクライアントの特権に基づいて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.
セキュリティサービスの提供で使用されるメカニズムとアルゴリズムは、必須のセキュリティポリシーごとに適切なレベルの保護を柔軟に指定できるように構成可能でなければなりません（MUST）。
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は、クライアントで実行されている異なるコンテキストが異なる暗号化キーとファシリティを使用できるように、コンテキスト細分性での認証をサポートする必要があります（SHOULD）。
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ラベルと属性のエンコーディングは、完全かつ明確な方法で指定する必要があります。これを達成するために、ラベルは、Label Format Specifier（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は、シンプルさと完全性を主な目的とする初期の交渉スキームを定義する必要があります（SHOULD）。これは、複雑で過度に一般化されたグローバルスキームに悩まされることなく、システムの実用的な展開を容易にするためです。将来の拡張性も考慮する必要があります。
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が変更された場合、システムはこれらの変更を反映するために契約を再交渉する必要があります（SHOULD）。
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ネゴシエーションがクライアントとサーバーでサポートされている場合、サーバーは、外部にあるファイルのソースに代わって動作する、クライアントとの新しい同時合意をネゴシエートする必要があります（SHOULD）。
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が有効になっている場合、サーバーポリシーの制限により、クライアントによって指定されたラベルを拒否することができます。サーバーは、オブジェクトのラベル付け規則が異なる場合に、オブジェクトに適切なラベルを見つけようとすべきではありません（SHOULD NOT）。サーバーはラベルの翻訳を許可されていますが、ラベルの意味の意味を変更してはなりません。
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.
ラベル付けと同様に、システムは、動的遷移によるプロセスセキュリティコンテキストの変更など、その他の揮発性クライアントセキュリティ状態も考慮に入れなければなりません（MUST）。アクセスの決定は、オブジェクトを開いたセキュリティラベルではなく、オブジェクトにアクセスしている現在のクライアントセキュリティラベルに基づいて行われる必要があります（異なる場合）。
The server SHOULD recall delegation of an object if the object's security label changes.
オブジェクトのセキュリティラベルが変更された場合、サーバーはオブジェクトの委任を再呼び出しする必要があります（SHOULD）。
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.
サーバーは、クライアントの資格情報に基づいて、セキュリティポリシーに従って、エクスポートされたファイルシステムの名前空間への選択的なアクセスを承認する手段を提供する必要があります（SHOULD）。
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モデルでは、すべてのオブジェクトにラベルが必要です。したがって、既存のサーバーをアップグレードしてLabeled NFSサポートを組み込む場合、既存のオブジェクトの動作を定義するのはセキュリティシステムの責任です。
In a Labeled NFS client and server interaction, we can describe three modes of operation:
ラベル付きNFSクライアントとサーバーの相互作用では、3つの操作モードを説明できます。
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機能のレベルを判別できなければなりません（MUST）。同様に、MAC機能サーバーは、クライアントがMAC機能サーバーであるかどうかを判別できなければなりません（MUST）。セクション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.
サーバーまたはクライアントの1つだけが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]を参照）クライアントとして動作する必要があり、ローカルプロセスのセキュリティ属性とネットワーク属性に基づいて、サーバーへのプロセスアクセスを選択的に提供する必要があります（SHOULD）。ポリシーに従って、サーバーの。クライアントは、これらのセキュリティ属性またはマウントポイントのラベル付けなどの他のラベル付け方法に基づいて、リモートファイルシステムのデフォルトのラベル付けをオーバーライドすることもできます。
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.
このケースの例は、ユーザーのホームディレクトリがリモートでマウントされ、ユーザーのブラウザーで実行されている悪意のあるWebスクリプトによってプライベートユーザーデータが読み取られることを防ぐために、きめ細かなMACポリシーが実装されている場合などです。ラベル付き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セキュリティラベルを簡単に保存および取得できることが望まれます。ラベル付き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）として定義します。検索されるディレクトリには「トップシークレット」というラベルが付いています。つまり、ディレクトリを読み取るためのアクセス権は、リクエストを行っているサブジェクトにも「トップシークレット」というラベルが付いている場合にのみ許可されます。
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.
シークレットで実行する代わりに、プロセスがトップシークレットで実行する2番目のケースを考えてみます。この場合、プロセスの機密性はディレクトリの機密性以上であるので、MACモジュールは要求を許可します。これで、readdir()はサーバーへの必要なNFSv4.2呼び出しに変換されます。リモートプロシージャコール（RPC）要求の場合、クライアントは適切な資格情報を使用して、プロセスがTop Secretで実行されていることをサーバーに表明します。
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モジュールをチェックして、Top SecretプロセスがTop Secretディレクトリの内容を読み取ることが許可されているかどうかを確認します。これはポリシーで許可されているため、サーバーは適切な情報をクライアントに返します。
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機能のクライアントと前のセクションの例を使用すると、結果は同じになります。 1つの違いは、すべての決定はクライアント側で行われることです。
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環境にあるかのように動作します。クライアント上のプロセスはセキュリティ属性を提供しないため、サーバーはクライアントからのすべての要求にラベルを付けるメカニズムを定義する必要があります。サーバーが最初の例と同じ基準を使用していると想定します。サーバーは、シークレットネットワークであるサブネットからの要求であると見なします。サーバーは、そのサブネット上のすべてのクライアントの要求にシークレットのラベルが付けられると判断します。サーバー上のディレクトリには「トップシークレット」というラベルが付けられており、シークレットはトップシークレットよりも優先されないため、サーバーはNFS4ERR_ACCESSで要求を失敗させます。
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対応サーバーとします。次に、MAC対応サーバーが非MAC機能クライアントからの要求を受け入れてはならないという追加のポリシーを持つ新しいLFS L 'を作成できます。
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]スモーリー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]ヘインズ、T。、「NFSバージョン4マイナーバージョン2」、作業中、2014年2月。
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC 4949, August 2007.
[RFC4949] Shirey、R。、「インターネットセキュリティ用語集、バージョン2」、RFC 4949、2007年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/ ja- US / Red_Hat_Enterprise_Linux / 5 / html / Deployment_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、「Remote Procedure Call（RPC）Security Version 3」、Work in Progress、2014年2月。
[SENFSv3] Carter, J., "Implementing SELinux Support for NFS", <http://www.nsa.gov/research/_files/selinux/papers/ nfsv3.pdf>.
[SENFSv3] Carter、J。、「Implementing SELinux Support for NFS」、<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、「System V Interface Definition（SVID）」、第3版、Addison-Wesley、Reading、MA、1989。
David Quigley was the early energy in motivating the entire Labeled NFS effort.
David Quigleyは、Labeled NFSの取り組み全体を動機づける初期のエネルギーでした。
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 Myklebustは、安全なディスクレスNFSクライアントの使用例を提供しました。
Both Nico Williams and Bryce Nordgren challenged assumptions during the review processes.
ニコウィリアムズとブライスノードグレンの両方が、レビュープロセス中に仮定に異議を唱えました。
Author's Address
著者のアドレス
Thomas Haynes NetApp 495 East Java Dr. Sunnyvale, CA 94089 USA
Thomas Haynes NetApp 495 East Java Dr. Sunnyvale、CA 94089 USA
Phone: +1 408 215 1519
EMail: tdh@excfb.com