a very, early view; but pls comment on any non-editorial issues thks, Fred
Fred Glover <fglover@decvax.dec.com> Wed, 05 February 1992 05:10 UTC
Received: from nri.reston.va.us by NRI.NRI.Reston.VA.US id aa05830; 5 Feb 92 0:10 EST
Received: from wdl1.wdl.loral.com by NRI.NRI.Reston.VA.US id aa05824; 5 Feb 92 0:10 EST
Received: by wdl1.wdl.loral.com (5.61+++/WDL-3.08) id AA00602; Tue, 4 Feb 92 20:21:32 -0800
Received: from decvax.dec.com by wdl1.wdl.loral.com (5.61+++/WDL-3.08) id AA00565; Tue, 4 Feb 92 20:20:44 -0800
Received: by decvax.dec.com (5.57/decvax-27Nov90) id AA12413; Tue, 4 Feb 92 23:21:02 -0500
Received: by abyss.zk3.dec.com (5.57/DEC-USSG-ZK3-ULTRIX-09/27/91); id AA04680; Tue, 4 Feb 92 23:20:59 -0500
Date: Tue, 04 Feb 1992 23:20:59 -0500
From: Fred Glover <fglover@decvax.dec.com>
Message-Id: <9202050420.AA04680@abyss.zk3.dec.com>
To: tnfs@wdl1.wdl.loral.com
Subject: a very, early view; but pls comment on any non-editorial issues thks, Fred
Sender: tnfs-request@wdl1.wdl.loral.com
================================================================== >>> Submissions to the tnfs list: tnfs@wdl1.wdl.loral.com >>> Additions/deletions/questions: tnfs-request@wdl1.wdl.loral.com >>> Archive Server: archive-server@wdl1.wdl.loral.com ================================================================== Request for Comments On A Specification of | Trusted NFS (TNFS) Protocol Extensions 1. Status Of This Memo This draft document specifies extensions to RFC 1094 [1] which support network file access in a multilevel secure (MLS) network environment[1]. This draft was approved by the Trusted Systems Interoperability Group (TSIG), whose charter is to promote multi-vendor trusted system interoper- ability. 2. Abstract Additional functionality has been developed for UNIXr sys- tems to address the TCSEC [2] requirements for trusted sys- tems. New requirements are driving efforts to develop interoperable, networked solutions for trusted UNIX environ- ments. A specific approach for addressing TCSEC MLS requirements is identified in the CMW requirements document [3]. Developing support for network interoperability among MLS classified systems is a primary goal of the trusted UNIX community. Sun Microsystem's Network File System (NFS- ) V2 protocol is an industry (de facto) standard network file access mechan- ism, and represents one of the key components of system interoperability in the current UNIX networking market. This draft document describes extensions to the NFS V2 protocol which support network file access in a MLS network environ- ment. It will be submitted to the RFC editor as a protocol specification. Distribution of this draft document is unlim- ited. Please send comments to the author at the address identified in section 6 below. 3. MLS Extensions for NFS MLS functionality includes discretionary access control (DAC), subject and object security labeling, mandatory access control (MAC), authentication, auditing, and documen- tation. Exchanging information between MLS systems requires communicating additional security information along with the actual data. _________________________ [1] Multilevel Secure systems include, for example, support for B1 and CMW security policies. r UNIX is a registered trademark of UNIX Systems La- boratories (U.S.L.) - NFS is a trademark of Sun Microsystems, Incorporat- ed TSIG-TNFS-001.2.01 WORKING GROUP REVIEW ONLY [Page 1] INTERNET-DRAFT TNFS Protocol Specification February 3, 1992 The primary goal of this specification is to describe exten- sions to the NFS V2 protocol which support network file access between MLS systems with a minimal impact on the existing NFS V2 environment[2]. It is also intended that this MLS environment will permit unmodified NFS clients and servers to continue to be fully supported. The general approach used in extending the NFS V2 protocol is to transport additional user context in the form of an extended NFS UNIX style credential between a Trusted NFS (TNFS) client and server, and to map that context into the appropriate server security policies which address file access. In addition, security file attributes are returned with each NFS (TNFS) procedure call. Otherwise, the NFS V2 protocol remains essentially unchanged. Two companion documents [4][5] complete the set of documen- tation describing the TNFS environment. 3.1. The Extended User Context The Sun RPC protocol [6][7] includes two authentication parameters in a request message: an authentication credential - used to identify or present a client subject's credentials to a server along with a given request for access or information, and an authentication verifier - used to validate the subject's credentials, and an authentication verifier in the RPC response message. An NFS server uses the client subject's credentials to per- form appropriate access checks prior to servicing the request. The verifier parameter in the RPC request message is used to authenticate the client subject's credentials[3]. Several styles of authentication are currently defined for NFS[4], and an NFS server may elect to support multiple authentication styles concurrently. A new RPC authentica- tion style, AUTH_MLS, is defined for use in the TNFS _________________________ [2] Revisions to the NFS V2 protocol have been speci- fied and presented for comment to the NFS community; this document addresses extensions to the V2 protocol only. [3] Authentication of client and server identities will not be addressed in this specification. [4] Styles currently defined are AUTH_NONE, AUTH_UNIX, AUTH_SHORT, and AUTH_DES. TSIG-TNFS-001.2.01 WORKING GROUP REVIEW ONLY [Page 2] INTERNET-DRAFT TNFS Protocol Specification February 3, 1992 environment. The definition of the AUTH_MLS credential com- bines the information in the AUTH_UNIX credential with extensions for the additional security attributes: o audit id - immutable subject (user) identifier, not affected by modifications to either the real or effective user or group identifiers, o sensitivity label - used with a MAC policy; a sub- ject generally has a static, top-level clearance, but is permitted to execute processes at a sensi- tivity level different from (i.e. lower than) his/her actual clearance, o information label - also used with a MAC policy; dynamically adjusted based upon the information content associated with the subject (or object), o integrity label - used with commercial, multi- party security policy (eg. Clark-Wilson [8], Biba [9]), o privilege mask - used to identify privileges (eg. chown, chmod) or "rights" granted to a given sub- ject, generally to override an existing security policy, and o vendor label - used to accommodate additional, vendor specific policies The additional security attributes will actually be represented within the AUTH_MLS credential by fixed size tokens, which can support multiple translation schemes through the use of an appropriate translation mechanism [5]. For instance, mechanisms such as M.I.T. Project Athena's Hesiod/BIND or Sun Microsystem's NIS[5] lookup service could be used to support the translation of tokens and security attribute information. There are several advantages to the use of a token transla- tion model. One major advantage is that the actual security attribute information may be defined within the translation service, while the attribute representation may be defined by a small, fixed sized token within the relatively small amount of unallocated space in the credential structure. A second advantage of a translation model is that it may accommodate multiple security policies and translations. Finally, a token translation model permits security policies to be developed independently from the translation mechan- ism. Tokens are transferred within the AUTH_MLS credential _________________________ [5] Network Information Service, known previously as the Yellow Pages Service TSIG-TNFS-001.2.01 WORKING GROUP REVIEW ONLY [Page 3] INTERNET-DRAFT TNFS Protocol Specification February 3, 1992 as opaque objects which are given context by the security policy mechanisms implemented by the TNFS clients and servers. Note that although tokens are defined as opaque objects, tokens which represent the same security attribute and which reside within the same translation scheme may be compared for equality. This characteristic permits tokens represent- ing a specific security attribute to be referenced in com- parisons without requiring the tokens to be translated. 3.2. Discretionary Access Control A Discretionary Access Control (DAC) policy provides for the restriction of subject access to objects based on the iden- tity of subjects and/or the groups for which they are members. Most secure systems address DAC requirements through the use of access control lists. Associated with each file is a list which identifies the set of user and group combinations authorized to access the file, along with the access privileges associated with each combination. The information contained in the AUTH_MLS credential of a TNFS client request includes user and group identification sufficient to permit the server to apply appropriate DAC policies in controlling access to its shared, local file objects. For example, the subject represented by the user and/or group identifiers contained in the client request may be checked against the access control list information asso- ciated with the referenced file on the server. Access con- trol list information is not required to be transmitted from the client to the server in support of a server based access control policy. Client based support for access control of server based file objects is discussed below in the section which describes the extended attribute cache. 3.3. Mandatory Access Control A Mandatory Access Control (MAC) policy provides for the restriction of subject access to objects based on the sensi- tivity of the information contained in the objects. MAC policies thus include assigning levels of trust or clearance to system users (subjects), and levels of sensitivity to system objects, and then ensuring that only users with suf- ficient clearance can access the classified information. 3.3.1. Sensitivity Labels When MAC policies are enabled, each system subject and object is created with a sensitivity label, and the system MAC policies compare the labels when determining access. The AUTH_MLS credential contains the sensitivity label information associated with the TNFS client subject TSIG-TNFS-001.2.01 WORKING GROUP REVIEW ONLY [Page 4] INTERNET-DRAFT TNFS Protocol Specification February 3, 1992 (application) making the access request. This information is sufficient to permit the MAC policy checking mechanism on the server to determine whether to permit access to the requested object or information. 3.3.2. Information Labels Information labels represent the actual sensitivity of a given subject or object, and permit the additional identifi- cation of control markings for a given piece of information. The information label is dynamically adjusted on both sub- jects and objects to the highest sensitivity level reflected by a subject/object pair: if a subject issues a write request to an object, the information label of the object will be adjusted (if necessary) to the level defined by the information label of the subject; if a subject issues a read request to an object, the information label of the sub- ject will be adjusted to the level defined by the informa- tion label of the object. Note that information labels are adjusted upwards as a result of these actions; information labels are never automatically adjusted to a lower level. The AUTH_MLS credential in the RPC request message contains the current information label associated with a TNFS client application (subject), and permits a remote file's object information label to be adjusted (if necessary) as a result of a client generated write operation. The TNFS reply mes- sage includes a field for the information label associated with an accessed file object, permitting the subject's information label to be adjusted (if necessary) as a result of a client generated read operation. These extensions are sufficient to support the MAC informa- tion label policies with respect to network file access. 3.3.3. Privilege The TCSEC notion of appropriate privilege is an integral part of the MLS environment. It is expected that a subject with appropriate privilege will want to gain access to the additional file attribute information for the purposes of modification and/or viewing of that information. Subject privileges are defined within the AUTH_MLS credential. Note, however, that the privileges associated with a given subject on a given client system may not be extended to the subject on a given server. Although most subjects will likely retain their privileges on the server, a client administrator, for example, may not be granted administra- tive privileges on the server. | 3.3.4. File Name Attributes | UNIX file names may vary in length from 1 to 255 characters, | TSIG-TNFS-001.2.01 WORKING GROUP REVIEW ONLY [Page 5] INTERNET-DRAFT TNFS Protocol Specification February 3, 1992 and represent an additional data storage mechanism which | must be protected by appropriate MLS policies. Generally, | the contents of a file may be classified, but the name of | the file or knowledge of its existence is not. In some | cases, however, the name of the file as well as its contents | may require classification and protection. For example, | consider the following file name: | codeword.SAND_AIRDEF.is.the.TOP- | SECRET.DESERT_STORM.air.defense.project | The association of sensitivity and information labels with | directory file name entries provides the support necessary | to protect the use of classified file names. 3.4. Additional MLS Extensions for NFS In an MLS environment, both DAC and MAC access control poli- cies are applied in determining access to a given object. In a network environment of MLS systems participating in TNFS file access, the AUTH_MLS credential permits a TNFS server to apply both DAC and MAC policies in consideration of a request from a remote NFS client subject. Thus, MLS based network file access using the NFS V2 protocol can be supported through the use of the AUTH_MLS credential as described. Listing or modifying the DAC and MAC security attributes of | a server's file or file name from a client, however, requires additional protocol extensions. Identifying addi- tional security access restrictions when a request is made to open a remote file is also considered to be a require- ment. Extensions designed to satisfy these requirements are addressed by TNFS, and are described in the next subsec- tions. 3.4.1. Remote Access to Extended File Attributes The DAC and MAC security attribute information includes MAC and information labels, and access control list information (ACLs). Supporting remote access to this information is more difficult to address in the network environment, since: o it requires transmitting additional file security attribute information (or its representation) "over the wire", and o additional file attribute information cannot be accommodated in the existing NFS V2 protocol file attribute data structures; additional support for setting and getting the extended security attri- butes is required TSIG-TNFS-001.2.01 WORKING GROUP REVIEW ONLY [Page 6] INTERNET-DRAFT TNFS Protocol Specification February 3, 1992 Thus, extensions to the NFS V2 protocol procedures have been | defined to support access to the extended attributes of | served files and file names. The complete set of NFS proto- col procedures and security extensions are referred to in this document as the TNFS protocol. 3.4.2. File Open Enhancement Using the NFS V2 protocol, a client request to open (2) a remote file on the server may be translated by the client into a GETATTR procedure call for the current directory[6], followed by a LOOKUP procedure call for the file to be opened. If valid responses from these procedure calls are returned, the client's NFS file attribute cache is updated, and an open file descriptor may be returned to the request- ing application. Since the NFS V2 protocol does not transmit an actual open request to the server, however, an MLS server will not be able to apply the appropriate DAC and MAC policy at the time of the open request, and the application may find that it has successfully opened the file, but that it cannot access the file due to stronger access control policies being applied by the server in response to specific client access requests. An access protocol procedure would permit the client to determine whether access to the file would be supported by the server, based on the application's open request type and the associated extended security attribute information. The ACCESS TNFS protocol procedure has been defined to address this issue. 3.4.3. File Name Enhancement | Supporting the retrieval of the additional security attri- | butes associated with each file name requires an extension | to the directory result structure returned by the NFS direc- | tory procedures: LOOKUP, CREATE, and MKDIR. This extension | is defined in the next section. | The ability to modify the file name security attributes | independently from the file data security attributes is also | considered to be a requirement. A new TNFS procedure, SET- | LABEL, has been defined to accommodate this issue. | 3.4.4. Multi-Level Directory Enhancement | Directories are files which contain file names and pointers | to the file data associated with the file names. The files | _________________________ [6] Depends on the presence of valid attributes in the lookup cache (DNLC). TSIG-TNFS-001.2.01 WORKING GROUP REVIEW ONLY [Page 7] INTERNET-DRAFT TNFS Protocol Specification February 3, 1992 contained in a directory include both regular files as well | as other subdirectory files. Directories are used to group | files, and to support the file system hierarchy. Each UNIX | system user typically maintains a personal or home direc- | tory, which contains files that belong to that user. The | UNIX system also maintains a set of directories: some for | its own use, and some, such as the /tmp directory, for use | by all members of its user community. | In an MLS environment, files and directories are labeled | with specific classifications. Security policies limit the | access of files to users with appropriate classifications. | MLS implementations must continue to maintain the basic file | system directory hierarchy, and also support the MLS access | policies. They must support the creation, storage, and | access of files and data of different security classifica- | tions, and provide some accommodation for the use of com- | monly shared directories, such as /tmp and /usr/tmp. | Several implementation mechanisms have been developed to | address these issues [4]. One implementation makes use of a | set of diversion directories which are created below the | actual MultiLevel Directory (MLD). Each divergent directory | is associated with a specific classification level, and user | access is directed into the appropriate divergent directory | in a transparent, pass-through manner. Another implementa- | tion makes use of the file name security attributes and | maintains each directory as an MLS directory. | An important TNFS goal is to identify the protocol pro- | cedures and extensions required to support MLS implementa- | tions. The addition of the file name security attributes and | the TNFS SETLABEL procedure described previously accommo- | dates the MLS MultiLevel Directory implementations. The | TNFS MLD procedure has been defined to accommodate the | divergent MultiLevel Directory implementations. | 3.4.5. TNFS Protocol Extensions Extensions to the NFS V2 protocol are defined in this sec- tion of the specification. These extensions are designed to support remote access to the security file attribute exten- sions, and to support the file open enhancement. 3.4.5.1. Data Structure Definitions The definitions which support the MLS extensions are described in this section. Since the definitions for the TNFS protocol are an extension of the original NFS V2 proto- col, this specification will include all of the extended data structure definitions, and a few of the original defin- itions for clarity. Note that the arguments and results are defined using the RPC language. TSIG-TNFS-001.2.01 WORKING GROUP REVIEW ONLY [Page 8] INTERNET-DRAFT TNFS Protocol Specification February 3, 1992 The following RPC constants are used to identify the TNFS extensions which support MLS security policies. The TNFS program will be registered as a separate service with the RPC port mapping service.[7] Registration as a different service distinguishes the TNFS service from the original NFS V2 service. The use of a different version number distin- guishes each request/response message. PROGRAM 390086 /* TNFS Program Number */ VERSION 1 /* TNFS Version 1 */ The stat type is returned from every procedure call. A value of NFS_OK indicates the call completed successfully. Other values indicate that an error occurred during the ser- vicing of the request. Note: this structure is unchanged from the NFS V2 Protocol Specification. It is (partially) reproduced here for clarity. stat enum stat { NFS_OK = 0, NFSERR_PERM = 1, NFSERR_NOENT = 2, . . . [other NFS errors as defined in the V2 protocol specification] }; The credential parameter is included in each RPC request message, and is used to supply the client subject's creden- tials to the server. The AUTH_MLS credential will be used with the TNFS procedure calls and is defined as follows: #define AUTH_MLS 200000 /* decimal */ #define MLS_TOKEN_SIZE 4 /* 4 octets or 32 bits */ typedef opaque t_token[MLS_TOKEN_SIZE]; /* tokens are opaque */ struct authmls_cred { u_long auc_stamp; /* arbitrary ID */ char auc_machname<255>; /* machine name */ _________________________ [7] TNFS server implementations may elect to share a common UDP [13] port number with the original NFS V2 service, or to make use of a different port number. TSIG-TNFS-001.2.01 WORKING GROUP REVIEW ONLY [Page 9] INTERNET-DRAFT TNFS Protocol Specification February 3, 1992 u_long auc_uid; /* effective uid */ u_long auc_gid; /* effective gid */ u_long auc_len; /* len of groups list */ u_long auc_gids<24>; /* groups */ u_long auc_aid; /* audit id */ t_token auc_privs; /* privileges token */ t_token auc_sens; /* sensitivity token */ t_token auc_info; /* information token */ t_token auc_integ; /* integrity token */ t_token auc_vend; /* vendor specific policy token */ }; Note that if a given security attribute is not being exchanged, then the corresponding credential token | value shall be set to "all bits on". A given security policy may require that only a subset of the security attributes provided for in this specification be exchanged. For example, a C2 network security policy requires the support of privileges, and might also require support for Access Control Lists (ACLs). In that case, the sensitivity, information, integrity, and vendor specific token values shall be set to "all bits | on" in the exchange messages. The fattr structure defines the complete set of file attri- butes of a file. The extended fattr structure combines the NFS V2 fattr structure with additional fields for a file's security attributes. The security attributes are represented by tokens. struct fattr { ftype type; /* file type */ u_long mode; /* encoded access mode */ u_long nlink; /* number of hard links */ u_long uid; /* file's owner id */ u_long gid; /* file's group id */ u_long size; /* file size in bytes */ u_long blocksize; /* number bytes/block */ u_long rdev; /* device number of the file */ u_long blocks; /* current number of blocks */ u_long fsid; /* file system id */ u_long fileid; /* unique file identifier */ timeval atime; /* time of file's last access */ timeval mtime; /* time last modified (written) */ timeval ctime; /* time of last attribute change */ t_token privs; /* privileges token */ t_token sens; /* sensitivity token */ t_token info; /* information token */ t_token integ; /* integrity token */ t_token acl; /* access control list token */ t_token vend; /* vendor specific policy token */ TSIG-TNFS-001.2.01 WORKING GROUP REVIEW ONLY [Page 10] INTERNET-DRAFT TNFS Protocol Specification February 3, 1992 }; Note that if a given security attribute is not being exchanged, then the corresponding file attribute token | value shall be set to "all bits on". The sattr structure defines the file attributes which can be set from the client. The extended sattr structure combines the NFS V2 sattr structure with additional fields for the security attributes, which are represented by tokens. A token value of "all bits on" indicates that the token field | is to be ignored. struct sattr { u_long mode; /* encoded access mode */ u_long uid; /* file's owner id */ u_long gid; /* file's group id */ u_long size; /* file size in bytes */ timeval atime; /* last access time */ timeval mtime; /* last data modify time */ t_token privs; /* privileges token */ t_token sens; /* sensitivity token */ t_token info; /* information token */ t_token integ; /* integrity token */ t_token acl; /* access control list token */ t_token vend; /* vendor specific policy token */ }; The sattrargs structure is used by the SETATTR procedure. It contains the extended sattr structure definition. struct sattrargs { fhandle file; sattr attributes; }; The attrstat structure defines a common procedure result containing the status of the procedure call. It is returned with the results of GETATTR, SETATTR, and WRITE procedure calls. If the call was successful, attrstat contains the results for the specific procedure called, and the complete set of file attributes for the file on which the procedure was executed. union attrstat switch (stat status) { case NFS_OK: fattr attributes; default: TSIG-TNFS-001.2.01 WORKING GROUP REVIEW ONLY [Page 11] INTERNET-DRAFT TNFS Protocol Specification February 3, 1992 void; }; The diropres structure defines the results of a directory procedure call. If the call was successful, diropres con- tains a new file handle file and the complete set of associ- ated file attributes. union diropres switch (stat status) { case NFS_OK: struct { fhandle file; fattr attributes; t_token sens; | t_token info; | } diropok; default: void; }; The readlinkres structure defines the results of a READLINK procedure call. If the call was successful, readlinkres contains the data in the symbolic link of the file identi- fied by the file handle argument, and the complete set of associated file attributes. File attributes are returned with the READLINK procedure call to support the information label adjustment policy. union readlinkres switch (stat status) { case NFS_OK: struct { path data; fattr attributes; } readlinkok; default: void; }; The readdirres structure defines the results of a READDIR procedure call. If the call was successful, readdirres returns a variable number of directory entries, with a total size of up to the amount specified in the argument count of the readdirargs structure. Each entry contains a unique file identifier, and an opaque "pointer" to the next entry in the directory. The eof flag has a value of TRUE if there are no more directory entries. File attributes are returned with the READDIR procedure call to support the information label adjustment policy. TSIG-TNFS-001.2.01 WORKING GROUP REVIEW ONLY [Page 12] INTERNET-DRAFT TNFS Protocol Specification February 3, 1992 union readdirres switch (stat status) { case NFS_OK: struct { entry *entries; bool eof; fattr attributes; } readdirok; default: void; }; 3.4.5.2. TNFS Protocol Procedure Definitions The TNFS Protocol Definition integrates the use of: o the extended fattr and sattr structures, o an AUTH_MLS authentication style RPC credential, o a new TNFS protocol version number to differen- | tiate between NFS V2 and the security extended | TNFS protocol, o a new protocol procedure, ACCESS, to support the | file open enhancement, | o a new protocol procedure, SETLABEL, to support the | modification of the file name security attributes, | and | o a new protocol procedure, MLD, to support diver- | gent MultiLevel Directories Other than these changes, however, the syntax and semantics of TNFS remain the same as in the original NFS V2 specifica- tion. 3.4.5.2.1. Access Procedure The following descriptions are used to define the new ACCESS procedure. Definitions used to identify the access request type: #define READ 0x001 #define WRITE 0x002 #define EXEC 0x004 #define SEARCH 0x008 #define APPEND 0x010 Arguments for the remote access procedure: TSIG-TNFS-001.2.01 WORKING GROUP REVIEW ONLY [Page 13] INTERNET-DRAFT TNFS Protocol Specification February 3, 1992 accessargs struct accessargs { fhandle file; u_long flag; }; Response from the remote access procedure: accessres union accessres switch ( stat status ) { case NFS_OK: struct { bool_t status; /* access status: TRUE or FALSE */ fattr attributes; /* standard file attri- butes */ } accessok; default: void; }; Procedure definition for checking remote access permission: accessres NFSPROC_ACCESS(accessargs) = 18 Description: Determine if access as described by flag will be per- mitted on the remote served object file by the reques- ter. Flag values are bit encoded as defined previ- ously. READ access means that the data in file can be read, WRITE access means that the data in file can be modified (written), EXEC access means that file can be accessed and executed (local execution of a remote file), SEARCH access means that the directory file can be used as the argument to a LOOKUP operation, and APPEND means that the file size can be extended. If status is NFS_OK: accessok.status will be set to TRUE if the access request would be allowed, and set to FALSE other- wise, and attributes will contain the complete set of file attributes Otherwise: TSIG-TNFS-001.2.01 WORKING GROUP REVIEW ONLY [Page 14] INTERNET-DRAFT TNFS Protocol Specification February 3, 1992 the NFSERR error number returned identifies the error condition Implementation: The ACCESS procedure provides a means for checking file access permission prior to issuing a subsequent set of file operations. For example, a TNFS client may issue an access procedure as a result of an application's file open (2) request to determine if subsequent file reads and/or writes by the application would be denied by the server as a result of the server's extended file access security policies. Note that the information returned by the server in response to an ACCESS pro- cedure call is not static; subsequent file administra- tive procedures may result in the modification of the file's security attributes. 3.4.5.2.2. Set Label Procedure | The following descriptions are used to define the new SETLA- | BEL procedure. | Arguments for the set label procedure: | setlabargs | struct setlabargs { | struct diropargs dirargs; | t_token sens; | t_token info; | }; | The results of the SETLABEL procedure are returned in a | diropres structure. If the call succeeded, a new file han- | dle "file", the file "attributes" associated with that file, | and the security attributes associated with the file name | are returned along with the "status". | Procedure definition for setting file name security attri- | butes: | diropres | NFSPROC_SETLABEL(setlabargs) = 19 | Description: | Set the file name security attributes, the sensitivity | label sens, and the information label info, on the file | name name in the parent directory dir. If status is | NFS_OK: | TSIG-TNFS-001.2.01 WORKING GROUP REVIEW ONLY [Page 15] INTERNET-DRAFT TNFS Protocol Specification February 3, 1992 then the reply file and reply attributes are the | file handle and attributes for the file name in | the directory given by dir in the argument, and | the reply sens and repl info are the sensitivity | and information labels for the file name name. | Otherwise: | the NFSERR error number returned identifies the | error condition | Implementation: | The SETLABEL procedure provides a means for modifying | the file name security attributes, the sensitivity and | information labels associated with the file name | object. When a file is created, the file name sensi- | tivity label will be set equal to the sensitivity label | associated with the file data, and the information | label will be set to "SYSTEM LOW". Once the file is | created, however, the sensitivity and information | labels of the file name and the file data are main- | tained independently. The file data security attribute | information is maintained by SETATTR, and the file name | security attribute information is maintained by SETLA- | BEL. | 3.4.5.2.3. MLD Procedure | The following descriptions are used to define the new MLD | procedure. | Definitions used to identify the MLD request type: | #define CREATE 0x001 | #define REMOVE 0x002 | #define ISMLD 0x004 | Arguments for the MLD procedure: | mldargs | struct mldargs { | fhandle file; | u_long flag; | }; | Response from the remote access procedure: | mldres | TSIG-TNFS-001.2.01 WORKING GROUP REVIEW ONLY [Page 16] INTERNET-DRAFT TNFS Protocol Specification February 3, 1992 union mldres switch ( stat status ) { | case NFS_OK: | struct { | bool_t status; /* ISMLD status: TRUE or | FALSE */ | fattr attributes; /* standard file attri- | butes */ | } mldok; | default: | void; | }; | Procedure definition for maintaining MultiLevel Directories: | mldres | NFSPROC_MLD(mldargs) = 20 | Description: | Support the creation and removal of divergent, Mul- | tiLevel Directories, and support also the ability to | determine if a given directory is an MLD. Flag values | are bit encoded as defined previously. CREATE indicates | that an MLD is to be created, REMOVE indicates that an | MLD is to be destroyed. ISMLD requests that the MLD | status of the file be returned. If status is NFS_OK: | if the flag was ISMLD, then mldok.status will be | set to TRUE if the file is a MultiLevel Directory, | and set to FALSE otherwise | if the flag was not ISMLD, then the mldok.status | flag has no meaning | attributes will contain the complete set of file | attributes | Otherwise: | the NFSERR error number returned identifies the | error condition | Implementation: | The MLD procedure provides the means for creating, | removing, and checking for the existence of a Mul- | tiLevel Directory (MLD). | 3.4.5.2.4. TNFS Service Routines The TNFS protocol definition is defined below as a set of TSIG-TNFS-001.2.01 WORKING GROUP REVIEW ONLY [Page 17] INTERNET-DRAFT TNFS Protocol Specification February 3, 1992 procedures, arguments, and results. All modified data structure definitions are included in this specification. Most NFS V2 protocol data definitions remain unchanged, and are documented in the NFS V2 protocol specification. The complete set of TNFS protocol procedures are defined below. The ACCESS, SETLABEL, and MLD procedures are new, but the | other procedures are the same as those defined in the NFS V2 specification. The GETATTR, SETATTR, LOOKUP, READLINK, READ, WRITE, CREATE, MKDIR, READDIR, ACCESS, SETLABEL, and | MLD procedures for the TNFS protocol, however, include the | extended file attribute structure fattr in the response mes- sage. program TNFS_PROGRAM { version TNFS_VERSION { void NFSPROC_NULL (void) = 0; attrstat NFSPROC_GETATTR (fhandle) = 1; attrstat NFSPROC_SETATTR (sattrargs) = 2; diropres NFSPROC_LOOKUP (diropargs) = 4; readlinkres NFSPROC_READLINK (fhandle) = 5; readres NFSPROC_READ (readargs) = 6; attrstat NFSPROC_WRITE (writeargs) = 8; diropres NFSPROC_CREATE (createargs) = 9; stat NFSPROC_REMOVE (diropargs) = 10; stat NFSPROC_RENAME (renameargs) = 11; stat NFSPROC_LINK (linkargs) = 12; stat NFSPROC_SYMLINK (symlinkargs) = 13; diropres NFSPROC_MKDIR (createargs) = 14; stat NFSPROC_RMDIR (diropargs) = 15; readdirres NFSPROC_READDIR (readdirargs) = 16; statfsres NFSPROC_STATFS (fhandle) = 17; accessres NFSPROC_ACCESS (accessargs) = 18; diropres NFSPROC_SETLABEL (setlabargs) = 19; | mldres NFSPROC_MLD (mldargs) = 20; | } = 1; /* Trusted NFS Version 1 */ } = 390086; /* Trusted NFS Program Number */ 3.4.6. Using TNFS With the TNFS protocol procedures described above, listing and modifying remote extended file attributes is now sup- ported. The definition of a new application programming interface (API) to support the display of a file's security attributes will permit either a new file list command (e.g. lsacl, lsmac) or a modification to the existing ls (2) com- mand to display the security attribute information associ- ated with a remote file. Likewise, the definition of a new API for setting a file's security attributes will permit new change security attribute commands to be developed (e.g. chacl, chmac). The file open enhancement discussed previously may now be supported. The open API will be translated into a GETATTR operation for the current directory, a LOOKUP operation for TSIG-TNFS-001.2.01 WORKING GROUP REVIEW ONLY [Page 18] INTERNET-DRAFT TNFS Protocol Specification February 3, 1992 the file to be opened, and an ACCESS operation which returns a boolean value indicating whether the access requested would be permitted, along with the complete set of the file's attributes. Thus, the TNFS client can determine whether the application requesting to open the remote file will be able to access it based on the open request type and the application's security credentials. As described ear- lier, a server may choose to associate a set of privileges with the remote subject which are different from the privilege set associated with the subject on the client sys- tem. The ACCESS procedure call returns the server's assess- ment of the subject's access capabilities. The information label adjustment policy is supported, since | the AUTH_MLS credential contains the subject's information label, and the TNFS reply message contains an extended file attribute structure which includes the file object's infor- mation label. Note that the subject's information label may require adjustment as a result of reading a remote file (READ), reading a remote directory (READDIR), or reading a remote symbolic link (READLINK). A remote file's (object) information label may be adjusted as a result of SETATTR, WRITE, CREATE, RENAME, LINK, SYMLINK, and MKDIR TNFS pro- cedure calls. | File Name security attributes are supported. TBD. | MLS and divergent, MultiLevel Directories are supported. | TBD. 3.4.7. TNFS Access Control Policy The access control policy recommended by this proposal may be stated as follows: o a client system shall always apply the access con- trol policy to a local request for access to a local resource, o a server system shall always apply the access con- trol policy to a local request for access to a local resource, o a server system shall always apply the access con- trol policy to a remote access request for a local resource, and o a client system may (temporarily) apply the access control policy to a locally cached remote resource, iff: * client security attribute caching support is included in the implementation, and TSIG-TNFS-001.2.01 WORKING GROUP REVIEW ONLY [Page 19] INTERNET-DRAFT TNFS Protocol Specification February 3, 1992 * a client security attribute caching policy is enabled by the host security officer This TNFS access control policy ensures that no access will be made without the application of appropriate access con- trol. 3.4.8. TNFS Auditing Policy The auditing policy recommended by this proposal is stated | as follows. When the security auditing function is enabled: o an implementation shall: | (1) audit all local requests for local file | access: > a client system shall always audit a local request for access to a local resource, > a server system shall always audit a local request for access to a local resource (2) provide the capability to audit all remote | file access requests: > the client shall support the capability to audit local requests for access to remote resources on a server, and > the server shall support the capability to audit remote requests for access to local resources on the server[8] (3) enable client system auditing of local | requests for access to remote files by | default Thus, when the security auditing function is enabled: o all local requests for access to local files are | audited, o client system requests for access to remote files | are audited[9] | _________________________ [8] This option may require the auditing of the specific TNFS protocol procedure calls, since the pro- tocol procedures are not translated into actual "system calls" in many server implementations. [9] This is the default policy; site specific audit- TSIG-TNFS-001.2.01 WORKING GROUP REVIEW ONLY [Page 20] INTERNET-DRAFT TNFS Protocol Specification February 3, 1992 o the capability to audit remote file access by both | client and server is provided: * client system auditing may be enabled to | audit local requests for access to remote | resources; client system auditing is enabled | by default, * server system auditing may be enabled to | audit remote requests for access to local | resources o enabling of the remote file access auditing capa- bility shall be supported by a system management operation This TNFS policy ensures that each TNFS host shall audit | local requests for local file access, each TNFS client sys- | tem shall audit requests for remote file access (by | default), and both TNFS clients and servers shall have the | cability to enable auditing of remote file access activity. In a given network environment, it may be desirable to optionally disable auditing of remote access on either the client or the server to avoid duplication. 3.4.9. The Extended Attribute Cache NFS caching strategies are implementation specific, and are not part of the NFS protocol. Caching is also not required to support TNFS interoperability. This specification will therefore not include specific details on the issue of attribute caching. However, since the caching mechanisms are included in the NFS reference source code releases, and since attribute caching is critical for achieving NFS per- formance goals, several suggestions are included in this section. In most NFS client implementations, remote file attributes are cached on the client, improving performance and reducing network traffic. The attribute cache is updated frequently, as most NFS procedures return file attributes along with other requested information. A client side cache for the extended security file attri- butes should also be considered for similar reasons. Since all of the file's security attributes are returned with each TNFS file access request, an extended security attribute cache can now be maintained on the client. Extending the attribute validation procedure to include _________________________ ing policies are established by the site security off- icer. TSIG-TNFS-001.2.01 WORKING GROUP REVIEW ONLY [Page 21] INTERNET-DRAFT TNFS Protocol Specification February 3, 1992 validating the security file attributes permits the complete set of file attributes to be checked and refreshed if they are no longer valid. If the file's cached attributes are not valid, a GETATTR procedure call can be made. The TNFS reply to this procedure now includes the complete set of file attribute information, permitting all of the file's cached attributes to be refreshed. Cached attribute entries shall be aged and eventually flushed unless refreshed. Note again that an attribute caching policy is not part of the protocol, and is an implementation technique used to improve performance. During the window of time that the cache entry is valid, the client system applies the MLS access control policies on behalf of the server. It is recommended that if an implementation supports the use of client side attribute caching, it shall also support a mechanism for disabling the attribute cache. Additional implementation details are provided in [4]. 4. Related Requirements and Expectations This specification addresses extensions the NFS V2 protocol which accommodate network file access in a trusted, MLS net- work environment. Expectations for the environment for which this specification is applicable include: o the TNFS network environment is a trusted environ- ment: > TNFS authentication and message integrity support shall not be required > use of TNFS in an untrusted environment (i.e. commercial network environment) is not addressed by this specification o other, related RPC services are required to sup- port the execution of NFS; these services shall support the AUTH_MLS credential flavor, but may also support alternative policies which make use of other authentication flavors: > the token management service is required to translate security attributes between expanded and tokenized formats [5], > the mount service is required to support NFS mount requests, > the lock manager and status monitor services are required to support NFS file and file region locking o client side mounts shall be restricted to the TSIG-TNFS-001.2.01 WORKING GROUP REVIEW ONLY [Page 22] INTERNET-DRAFT TNFS Protocol Specification February 3, 1992 server's exported mount points: > client requests to mount a subdirectory which resides below the export point in the server's exported directory shall be denied, > without this restriction, client access to server files mounted below the server's export point bypass the authorization checks which would otherwise have been made using the access modes of the file components located higher in the server's exported tree[10] o most file access will take place between MLS modi- fied clients and servers, but some TNFS systems will continue to interoperate with NFS V2 systems through the use of an appropriate policy; for example, a filter or gateway could be placed between a MLS system and an unmodified system to insert or delete appropriate security attribute information on behalf of the unmodified system o a TNFS client should not send any security extended NFS procedure calls to a server which does not support this service; a TNFS client should also refrain from sending extraneous secu- rity attribute information to a TNFS server that does not support those attributes o additional TCB information[11] is maintained by each MLS system to support trusted interoperabil- ity [10]; for example, each MLS host may: > maintain a list of the hosts which it will communicate with, > maintain the set of security attributes which it expects to use in the exchange of data with a given host, and > maintain the specific translation scheme or schemes which will be used in translating tokens with a given host [5] _________________________ [10] Note that appropriate use of symbolic links on the client will result in a client file name space similar to one previously constructed by mounting sub- directories of exported server file trees. [11] Note that this information is needed by all trusted network applications, and is not limited to NFS file access. TSIG-TNFS-001.2.01 WORKING GROUP REVIEW ONLY [Page 23] INTERNET-DRAFT TNFS Protocol Specification February 3, 1992 o the security information defined within the AUTH_MLS credential and file attribute structures provides for the transfer of security attributes required to support MLS access policies without requiring the underlying network layer to provide security attribute information: > if security attributes are provided by both the RPC layer and the underlying network layer, then the security attribute informa- tion provided by the RPC layer shall be applied to the file data transferred within the RPC message > transferring security attributes within the RPC layer provides for the support of a pol- icy where data may be transferred with a security classification which is different from the security classification of the net- work layer; for instance, file data with a given security classification might first be encrypted and then transferred through a net- work with a lower security classification. > support for the transfer of MAC sensitivity labels for the Internet Protocol Suite has been addressed by the CIPSO [11], and RIPSO [12] documents 5. Conclusion This document describes the set of extensions which support network file access in a network environment consisting of MLS systems using the proposed TNFS protocol extensions. Unmodified NFS clients and servers are supported using the de facto NFS V2 protocol. With the previously defined extensions, the MLS network file access requirements are met. The extended structure defini- tions support the DAC and MAC attributes required for modi- fying or displaying the security attribute information. The enhanced file open operation and the information label adjustment policies are also supported. Thus, a small set of extensions to the NFS V2 environment permits MLS access control policies to be supported. Agree- ment on these changes will permit the current base of NFS clients and servers to be accommodated in the secure environment with no changes, and for TNFS modified systems to interoperate using MLS policies. 6. Acknowledgements I would like to acknowledge the members of the ITEF/TSIG NFS TSIG-TNFS-001.2.01 WORKING GROUP REVIEW ONLY [Page 24] INTERNET-DRAFT TNFS Protocol Specification February 3, 1992 Subcommittee, who were instrumental in evolving the MLS extended NFS Protocol Specification from the original propo- sal. Many comments were also made during the review of the later drafts which greatly improved the specification's rea- | dability. Contributing IETF TNFS working group members | include Jeff Edelheit, Fran Fadden, Ali Gohshan, Carl Smith, | Mark Saake, Dave Summers, and Charlie Watt. I'd also like | to acknowledge the contributions of the original members of | the TSIG Trusted NFS working group: in addition to the | above, these members included Morgan Clark, Tricia Jordan, | Will Lees, Scott Norton, and Mike Shipley. The specification was also reviewed by numerous persons out- side of the subcommittee. I would like to acknowledge these persons as well, as a number of their comments are also reflected in the final version. 7. Author's Address Fred Glover Digital Equipment Corporation 110 Spit Brook Road ZK03-3/U14 Nashua, New Hampshire 03062-2698 Phone: 603-881-0388 EMail: fglover@decvax.dec.com 8. References [1] Sun Microsystems, Inc., "Network Filesystem Specifica- tion", RFC-1094, DDN Network Information Center, SRI International, Menlo Park, CA. [2] National Computer Security Center, United States Depart- ment of Defense, "Trusted Computer Systems Evaluation Criteria" National Computer Security Center, Ft. George G. Meade, MD., 1985, DoD 5200.28-STD [3] Defense Intelligence Agency, United States Department of Defense, "Security Requirements for System High and Compartmented Mode Workstations", Defense Intelligence Agency, Washington, D.C., DIA document number DDS- 2600-5502-87 [4] Trusted Systems Interoperability Group, "The MLS NFS Implementor's Guide", TSIG Document [5] Trusted Systems Interoperability Group, "The MLS Token Translation Specification", TSIG Document [6] Sun Microsystems, Inc., "Remote Procedure Call Specifi- cation", RFC-1057, DDN Network Information Center, SRI International, Menlo Park, CA. TSIG-TNFS-001.2.01 WORKING GROUP REVIEW ONLY [Page 25] INTERNET-DRAFT TNFS Protocol Specification February 3, 1992 [7] Sun Microsystems, Inc., "External Data Representation Specification", RFC-1014, DDN Network Information Center, SRI International, Menlo Park, CA. [8] Clark, D. D. and David R. Wilson, "A Comparison of Com- mercial and Military Computer Security Policies", Proceedings of the 1987 IEEE Symposium on Security and Privacy, IEEE Computer Society Press, Washington, DC. [9] Biba, K. J., "Integrity Considerations for Secure Com- puter Systems", TR-76-372, Electronic Systems Division, Air Force Systems Command, U.S. Department of the Air Force, Hanscomb AFB, MA., April 1977 [10] Trusted Systems Interoperability Group, "Trusted Administration Specification", TSIG Document [11] Trusted Systems Interoperability Group, "Commercial IP Security Option", TSIG Document [12] "The Revised IP Security Option", RFC-1038, RFC-1108, DDN Network Information Center, SRI International, Menlo Park, CA. [13] Postel, J., "User Datagram Protocol", RFC-768, DDN Network Information Center, SRI International, Menlo Park, CA. TSIG-TNFS-001.2.01 WORKING GROUP REVIEW ONLY [Page 26]