Expiration Date: January 1993Request for Comments On A Specification ofTrusted NFS (TNFS) Protocol Extensions1. Status Of This MemoThis document is an Internet Draft. Internet Drafts are workingdocuments of the Internet Engineering Task Force (IETF), its Areas,and its Working Groups. Note that other groups may also distributeworking documents as Internet Drafts.Internet Drafts are draft documents valid for a maximum of sixmonths. Internet Drafts may be updated, replaced, or obsoletedby other documents at any time. It is not appropriate to useInternet Drafts as reference material or to cite them other thanas a "working draft" or "work in progress."Please check the I-D abstract listing contained in each InternetDraft directory to learn the current status of this or anyother Internet Draft.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 bythe Trusted Systems Interoperability Group (TSIG), whosecharter is to promote multi-vendor trusted system interoper-ability.2. AbstractAdditional functionality has been developed for UNIXr sys-tems to address the TCSEC [2] requirements for trusted sys-tems. New requirements are driving efforts to developinteroperable, networked solutions for trusted UNIX environ-ments. A specific approach for addressing TCSEC MLSrequirements is identified in the CMW requirements document[3]. Developing support for network interoperability amongMLS classified systems is a primary goal of the trusted UNIXcommunity.Sun Microsystem's Network File System (NFS- ) V2 protocol isan industry (de facto) standard network file access mechan-ism, and represents one of the key components of systeminteroperability in the current UNIX networking market. Thisdraft document describes extensions to the NFS V2 protocolwhich support network file access in a MLS network environ-ment. It will be submitted to the RFC editor as a protocolspecification. Distribution of this draft document is unlim-ited. Please send comments to the author at the addressidentified insection 6 below.3. MLS Extensions for NFSMLS functionality includes discretionary access control(DAC), subject and object security labeling, mandatoryaccess control (MAC), authentication, auditing, and documen-tation. Exchanging information between MLS systems requirescommunicating additional security information along with theactual 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-edTNFS-001.2.03 [Page 1]
INTERNET-DRAFT TNFS Protocol Specification July 06, 1992The primary goal of this specification is to describe exten-sions to the NFS V2 protocol which support network fileaccess between MLS systems with a minimal impact on theexisting NFS V2 environment[2]. It is also intended thatthis MLS environment will permit unmodified NFS clients andservers to continue to be fully supported.The general approach used in extending the NFS V2 protocolis to transport additional user context in the form of anextended NFS UNIX style credential between a Trusted NFS(TNFS) client and server, and to map that context into theappropriate server security policies which address fileaccess. In addition, security file attributes are returnedwith each NFS (TNFS) procedure call. Otherwise, the NFS V2protocol remains essentially unchanged.Two companion documents [4][5] complete the set of documen-tation describing the TNFS environment.3.1. The Extended User ContextThe Sun RPC protocol [6][7] includes two authenticationparameters 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 therequest. The verifier parameter in the RPC request messageis used to authenticate the client subject's credentials[3].Several styles of authentication are currently defined forNFS[4], and an NFS server may elect to support multipleauthentication 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 protocolonly. [3] Authentication of client and server identitieswill not be addressed in this specification. [4] Styles currently defined are AUTH_NONE,AUTH_UNIX, AUTH_SHORT, and AUTH_DES.TNFS-001.2.03 [Page 2]
INTERNET-DRAFT TNFS Protocol Specification July 06, 1992environment. The definition of the AUTH_MLS credential com-bines the information in the AUTH_UNIX credential withextensions 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 policiesThe additional security attributes will actually berepresented within the AUTH_MLS credential by fixed sizetokens, which can support multiple translation schemesthrough the use of an appropriate translation mechanism [5].For instance, mechanisms such as M.I.T. Project Athena'sHesiod/BIND or Sun Microsystem's NIS[5] lookup service couldbe used to support the translation of tokens and securityattribute information.There are several advantages to the use of a token transla-tion model. One major advantage is that the actual securityattribute information may be defined within the translationservice, while the attribute representation may be definedby a small, fixed sized token within the relatively smallamount of unallocated space in the credential structure. Asecond advantage of a translation model is that it mayaccommodate multiple security policies and translations.Finally, a token translation model permits security policiesto be developed independently from the translation mechan-ism. Tokens are transferred within the AUTH_MLS credential_________________________ [5] Network Information Service, known previously asthe Yellow Pages ServiceTNFS-001.2.03 [Page 3]
INTERNET-DRAFT TNFS Protocol Specification July 06, 1992as opaque objects which are given context by the securitypolicy mechanisms implemented by the TNFS clients andservers.Note that although tokens are defined as opaque objects,tokens which represent the same security attribute and whichreside within the same translation scheme may be comparedfor 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 ControlA Discretionary Access Control (DAC) policy provides for therestriction of subject access to objects based on the iden-tity of subjects and/or the groups for which they aremembers. Most secure systems address DAC requirementsthrough the use of access control lists. Associated witheach file is a list which identifies the set of user andgroup combinations authorized to access the file, along withthe access privileges associated with each combination.The information contained in the AUTH_MLS credential of aTNFS client request includes user and group identificationsufficient to permit the server to apply appropriate DACpolicies in controlling access to its shared, local fileobjects. For example, the subject represented by the userand/or group identifiers contained in the client request maybe 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 fromthe client to the server in support of a server based accesscontrol policy. Client based support for access control ofserver based file objects is discussed below in the sectionwhich describes the extended attribute cache.3.3. Mandatory Access ControlA Mandatory Access Control (MAC) policy provides for therestriction of subject access to objects based on the sensi-tivity of the information contained in the objects. MACpolicies thus include assigning levels of trust or clearanceto system users (subjects), and levels of sensitivity tosystem objects, and then ensuring that only users with suf-ficient clearance can access the classified information.3.3.1. Sensitivity LabelsWhen MAC policies are enabled, each system subject andobject is created with a sensitivity label, and the systemMAC policies compare the labels when determining access.The AUTH_MLS credential contains the sensitivity labelinformation associated with the TNFS client subjectTNFS-001.2.03 [Page 4]
INTERNET-DRAFT TNFS Protocol Specification July 06, 1992(application) making the access request. This informationis sufficient to permit the MAC policy checking mechanism onthe server to determine whether to permit access to therequested object or information.3.3.2. Information LabelsInformation labels represent the actual sensitivity of agiven 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 reflectedby a subject/object pair: if a subject issues a writerequest to an object, the information label of the objectwill be adjusted (if necessary) to the level defined by theinformation label of the subject; if a subject issues aread 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 areadjusted upwards as a result of these actions; informationlabels are never automatically adjusted to a lower level.The AUTH_MLS credential in the RPC request message containsthe current information label associated with a TNFS clientapplication (subject), and permits a remote file's objectinformation label to be adjusted (if necessary) as a resultof a client generated write operation. The TNFS reply mes-sage includes a field for the information label associatedwith an accessed file object, permitting the subject'sinformation label to be adjusted (if necessary) as a resultof 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. PrivilegeThe TCSEC/CMW concept of least privilege is an integral partof the MLS environment. Fine grained privileges are grantedto subjects (and associated processes), and executableobjects (files) according to a strict set of rules. All sub-jects are limited with respect to the system actions theymay perform. An executable object is also limited to aspecific set of actions, regardless of the subject whichexecutes the object. Privilege sets associated with a fileobject are used to adjust a process's privileges during theexecution of that object. Thus, at any given time, a sub-ject will possess only those privileges necessary to supportthe completion of its current task.Note, however, that the privileges associated with a subjecton a client system might not be extended to that subject ona given remote server system. Although most subjects willlikely retain their privileges on the server, a clientTNFS-001.2.03 [Page 5]
INTERNET-DRAFT TNFS Protocol Specification July 06, 1992administrator, for example, might not be granted administra-tive privileges on the server.For TNFS, subject privileges are defined within the AUTH_MLScredential, and file privileges are defined within the secu-rity file attributes.3.3.4. File Name AttributesUNIX file names may vary in length from 1 to 255 characters,and represent an additional data storage mechanism whichmust be protected by appropriate MLS policies. Generally,the contents of a file may be classified, but the name ofthe file or knowledge of its existence is not. In somecases, however, the name of the file as well as its contentsmay require classification and protection. For example,consider the following file name: codeword.SAND_AIRDEF.is.the.TOP- SECRET.DESERT_STORM.air.defense.projectThe association of sensitivity and information labels withdirectory file name entries provides the support necessaryto protect the use of classified file names.3.4. Additional MLS Extensions for NFSIn 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 inTNFS file access, the AUTH_MLS credential permits a TNFSserver to apply both DAC and MAC policies in considerationof a request from a remote NFS client subject. Thus, MLSbased network file access using the NFS V2 protocol can besupported through the use of the AUTH_MLS credential asdescribed.Listing or modifying the DAC and MAC security attributes ofa server's file or file name from a client, however,requires additional protocol extensions. Identifying addi-tional security access restrictions when a request is madeto open a remote file is also considered to be a require-ment. Extensions designed to satisfy these requirements areaddressed by TNFS, and are described in the next subsec-tions.3.4.1. Remote Access to Extended File AttributesThe DAC and MAC security attribute information includes MACand information labels, and access control list information(ACLs). Supporting remote access to this information ismore difficult to address in the network environment, since:TNFS-001.2.03 [Page 6]
INTERNET-DRAFT TNFS Protocol Specification July 06, 1992 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 requiredThus, extensions to the NFS V2 protocol procedures have beendefined to support access to the extended attributes ofserved files and file names. The complete set of NFS proto-col procedures and security extensions are referred to inthis document as the TNFS protocol.3.4.2. File Open EnhancementUsing the NFS V2 protocol, a client request to open (2) aremote file on the server may be translated by the clientinto a GETATTR procedure call for the current directory[6],followed by a LOOKUP procedure call for the file to beopened. If valid responses from these procedure calls arereturned, 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 openrequest to the server, however, an MLS server will not beable to apply the appropriate DAC and MAC policy at the timeof the open request, and the application may find that ithas successfully opened the file, but that it cannot accessthe file due to stronger access control policies beingapplied by the server in response to specific client accessrequests.An access protocol procedure would permit the client todetermine whether access to the file would be supported bythe server, based on the application's open request type andthe associated extended security attribute information. AnACCESS TNFS protocol procedure has been defined to addressthis issue. Thus, if file attributes are being cached onthe client, and the security attributes of a client processissuing a request to open a remote file have been modifiedsince the last time it issued an open request for that file,then an ACCESS procedure call shall be made to the server torevalidate the access rights of that client process._________________________ [6] Depends on the presence of valid attributes inthe lookup cache (DNLC).TNFS-001.2.03 [Page 7]
INTERNET-DRAFT TNFS Protocol Specification July 06, 19923.4.3. File Name EnhancementSupporting the retrieval of the security attributes associ-ated with each file name requires an extension to the direc-tory result structure returned by the NFS directory pro-cedures: LOOKUP, CREATE, and MKDIR. This data structureextension is defined insection 3.4.5.1.The ability to modify file name security attributes indepen-dently from file data security attributes is also required.A new TNFS procedure, SETLABEL, has been defined to supportthis capability.3.4.4. MultiLevel Directory EnhancementDirectories are files which contain file names and pointersto the data associated with the file names. The files con-tained in a directory include both regular files as well asother subdirectory files. Directories are used to groupfiles, and to support the file system hierarchy.In an MLS environment, files and directories are labeledwith specific classifications; security policies limit theaccess of a given file to a user with a classification whichdominates the file's classification. MLS implementationsmust continue to maintain the basic file system directoryhierarchy, and also support the MLS access policies. Theymust support the creation, storage, and access of files anddata of different security classifications, and also providesome accommodation for the use of commonly shared direc-tories, such as /tmp and /usr/tmp.One implementation approach is to use file name securityattributes, as described previously. The TNFS file nameattributes and SETLABEL procedure support this approach. Analternative is to create a set of diversion directoriesbelow the actual MultiLevel Directory. Each diversiondirectory is associated with a specific classificationlevel, and user access is directed into the appropriatediversion directory in a transparent, pass-through manner.The TNFS MLD procedure supports diversion directory imple-mentations. Additional information is provided in [4].3.4.5. TNFS Protocol ExtensionsExtensions to the NFS V2 protocol are defined in this sec-tion of the specification. These extensions are designed tosupport remote access to the security file attribute exten-sions, and to support the file open, file name, and Mul-tiLevel Directory enhancements.3.4.5.1. Data Structure DefinitionsThe definitions which support the MLS extensions areTNFS-001.2.03 [Page 8]
INTERNET-DRAFT TNFS Protocol Specification July 06, 1992described in this section. Since the definitions for theTNFS protocol are an extension of the original NFS V2 proto-col, this specification will include all of the extendeddata structure definitions, and a few of the original defin-itions for clarity. Note that the arguments and results aredefined using the RPC language.The following RPC constants are used to identify the TNFSextensions which support MLS security policies. The TNFSprogram will be registered as a separate service with theRPC port mapping service.[7] Registration as a differentservice distinguishes the TNFS service from the original NFSV2 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. Avalue 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 unchangedfrom 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 requestmessage, and is used to supply the client subject's creden-tials to the server. The AUTH_MLS credential will be usedwith the TNFS procedure calls and is defined as follows: #define AUTH_MLS 200000 /* decimal */_________________________ [7] TNFS server implementations may elect to share acommon UDP [13] port number with the original NFS V2service, or to make use of a different port number.TNFS-001.2.03 [Page 9]
INTERNET-DRAFT TNFS Protocol Specification July 06, 1992 #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 */ 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; /* subject 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 theNFS V2 fattr structure with additional fields for a file'ssecurity attributes. The security attributes arerepresented 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 */TNFS-001.2.03 [Page 10]
INTERNET-DRAFT TNFS Protocol Specification July 06, 1992 timeval mtime; /* time last modified (written) */ timeval ctime; /* time of last attribute change */ t_token privs; /* file 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 */ }; 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 beset from the client. The extended sattr structure combinesthe NFS V2 sattr structure with additional fields for thesecurity attributes, which are represented by tokens. Atoken value of "all bits on" indicates that the token fieldis 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; /* file 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 resultcontaining the status of the procedure call. It is returnedwith the results of GETATTR, SETATTR, and WRITE procedurecalls. If the call was successful, attrstat contains theresults for the specific procedure called, and the completeTNFS-001.2.03 [Page 11]
INTERNET-DRAFT TNFS Protocol Specification July 06, 1992set of file attributes for the file on which the procedurewas executed. union attrstat switch (stat status) { case NFS_OK: fattr attributes; default: void; };The diropargs structure is used in directory operations. Thefhandle dir is the directory containing file name name. struct diropargs { fhandle dir; filename name; };The diropres structure defines the results of a directoryprocedure call. If the call was successful, diropres con-tains a new file handle file, the complete set of associatedfile attributes, and the file name attributes: sens, info,and vend. union diropres switch (stat status) { case NFS_OK: struct { fhandle file; fattr attributes; t_token sens; t_token info; t_token vend; } diropok; default: void; };The readlinkres structure defines the results of a READLINKprocedure call. If the call was successful, readlinkrescontains the data in the symbolic link of the file identi-fied by the file handle argument, and the complete set ofassociated file attributes. File attributes are returnedwith the READLINK procedure call to support the informationlabel adjustment policy. union readlinkres switch (stat status) { case NFS_OK:TNFS-001.2.03 [Page 12]
INTERNET-DRAFT TNFS Protocol Specification July 06, 1992 struct { path data; fattr attributes; } readlinkok; default: void; };The readdirres structure defines the results of a READDIRprocedure call. If the call was successful, readdirresreturns a variable number of directory entries, with a totalsize of up to the amount specified in the argument count ofthe readdirargs structure. Each entry contains a unique fileidentifier, the name of the file, and an opaque "pointer" tothe "next" entry in the directory, which is used in a subse-quent READDIR procedure call to obtain additional entriesstarting at that "point" in the directory. The eof flag hasa value of TRUE if there are no more directory entries. ForTNFS, file attributes are returned with the READDIR pro-cedure call to support the information label adjustment pol-icy.Note that in responding to a READDIR procedure call, theserver shall return only those directory entries which therequesting client process dominates. Thus, security attri-bute tokens are not required to be returned with each entry,and the directory information which is returned may bepassed to the requesting process without additional process-ing by the client TCB. 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 DefinitionsThe 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,TNFS-001.2.03 [Page 13]
INTERNET-DRAFT TNFS Protocol Specification July 06, 1992 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- sion directoriesOther than these changes, however, the syntax and semanticsof TNFS remain the same as in the original NFS V2 specifica-tion.3.4.5.2.1. Access ProcedureThe following descriptions are used to define the new ACCESSprocedure.Definitions used to identify the access request type: #define READ 0x001 #define WRITE 0x002 #define EXEC 0x004 #define SEARCH 0x008 #define APPEND 0x010Arguments for the remote access procedure: 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;TNFS-001.2.03 [Page 14]
INTERNET-DRAFT TNFS Protocol Specification July 06, 1992 };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: 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 processing of an open (2) request for a remote file shall include an ACCESS procedure call if the security attributes of the issuing client process have been modified since the last time that process issued an open request for that file. Note also that the information returned by the server in response to an ACCESS procedure call is not static; subsequent file administrative procedures may result in the modification of the file's security attributes.TNFS-001.2.03 [Page 15]
INTERNET-DRAFT TNFS Protocol Specification July 06, 19923.4.5.2.2. Set Label ProcedureThe 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; t_token vend; };Response from the set label procedure: diropres union diropres switch ( stat status ) { case NFS_OK: struct { fhandle file; fattr attributes; t_token sens; t_token info; t_token vend; } diropok; default: void; };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, the information label info, and the vendor specific policy label vend on the file name name in the parent directory dir. If status is NFS_OK: 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, andTNFS-001.2.03 [Page 16]
INTERNET-DRAFT TNFS Protocol Specification July 06, 1992 the reply sens, reply info, and reply vend are the sensitivity, information, and vendor specific pol- icy 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, information, and vendor specific policy labels associ- ated with the file name object. When a file is created, the file name sensitivity label will be set equal to the sensitivity value identified in the credential structure, and the file name information label will be set to the information value identified in the credential structure. Once the file is created, however, the sensitivity and information labels of the file name and the file data are maintained indepen- dently. The file data security attribute information is maintained by SETATTR, and the file name security attribute information is maintained by SETLABEL.3.4.5.2.3. MultiLevel Diversion Directory ProcedureThe following descriptions are used to define the new pro-cedure to support diversion directories.Definitions used to identify the MLD request operations: #define CREATE 1 #define REMOVE 2 #define ISMLD 3Arguments for the MLD procedure: mldargs struct mldargs { fhandle file; u_long op; };Response from the remote access procedure: mldres union mldres switch ( stat status ) {TNFS-001.2.03 [Page 17]
INTERNET-DRAFT TNFS Protocol Specification July 06, 1992 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 diversion directories: mldres NFSPROC_MLD(mldargs) = 20 Description: Support the creation and removal of diversion direc- tories, and the ability to determine if a given direc- tory is a diversion directory. The CREATE operation requests that a diversion directory be created, the REMOVE operation requests that a diversion directory be destroyed, and the ISMLD operation requests that the diversion status of the file be returned. If status is NFS_OK: if the mldargs.op was ISMLD, then mldok.status will be set to TRUE if the file is a diversion directory, and set to FALSE otherwise if the mldargs.op was not ISMLD, then mldok.status 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 diversion directory. MultiLevel Directory implementations which make use of file name attributes shall return status of NFS_OK in response to CREATE, REMOVE, and ISMLD requests, sinceTNFS-001.2.03 [Page 18]
INTERNET-DRAFT TNFS Protocol Specification July 06, 1992 all directories are MultiLevel Directories in such an environment and thus no explicit action is required.3.4.5.2.4. TNFS Service RoutinesThe TNFS protocol definition is defined below as a set ofprocedures, arguments, and results. All modified datastructure definitions are included in this specification.Most NFS V2 protocol data definitions remain unchanged, andare documented in the NFS V2 protocol specification. Thecomplete set of TNFS protocol procedures are defined below.The ACCESS, SETLABEL, and MLD procedures are new, but theother procedures are the same as those defined in the NFS V2specification. The GETATTR, SETATTR, LOOKUP, READLINK,READ, WRITE, CREATE, MKDIR, READDIR, ACCESS, SETLABEL, andMLD procedures for the TNFS protocol, however, include theextended 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 TNFSWith the TNFS protocol procedures described above, listingand modifying remote extended file attributes is now sup-ported. The definition of a new application programminginterface (API) to support the display of a file's securityattributes 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 newAPI for setting a file's security attributes will permit newTNFS-001.2.03 [Page 19]
INTERNET-DRAFT TNFS Protocol Specification July 06, 1992change security attribute commands to be developed (e.g.chacl, chmac).The file open enhancement discussed previously may now besupported. The open API will be translated into a GETATTRoperation for the current directory, a LOOKUP operation forthe file to be opened, and an ACCESS operation which returnsa boolean value indicating whether the access requestedwould be permitted, along with the complete set of thefile's attributes. Thus, the TNFS client can determinewhether the application requesting to open the remote filewill be able to access it based on the open request type andthe application's security credentials. As described ear-lier, a server may choose to associate a set of privilegeswith the remote subject which are different from theprivilege 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, sincethe AUTH_MLS credential contains the subject's informationlabel, and the TNFS reply message contains an extended fileattribute structure which includes the file object's infor-mation label. Note that the subject's information label mayrequire adjustment as a result of reading a remote file(READ), reading a remote directory (READDIR), or reading aremote 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 names may now be protected by MLS policy with theintroduction of file name security attributes, and the SET-LABEL procedure.Finally, MultiLevel Directories are accommodated.3.4.7. TNFS Access Control PolicyThe access control policy recommended by this proposal maybe 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, andTNFS-001.2.03 [Page 20]
INTERNET-DRAFT TNFS Protocol Specification July 06, 1992 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 * a client security attribute caching policy is enabled by the host security officerThis TNFS access control policy ensures that no access willbe made without the application of appropriate access con-trol.3.4.8. TNFS Auditing PolicyThe auditing policy recommended by this proposal is statedas 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_________________________ [8] This option may require the auditing of thespecific TNFS protocol procedure calls, since the pro-tocol procedures are not translated into actual "systemcalls" in many server implementations.TNFS-001.2.03 [Page 21]
INTERNET-DRAFT TNFS Protocol Specification July 06, 1992Thus, 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] 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 operationThis TNFS policy ensures that each TNFS host shall auditlocal requests for local file access, each TNFS client sys-tem shall audit requests for remote file access (bydefault), and both TNFS clients and servers shall have thecability to enable auditing of remote file access activity.In a given network environment, it may be desirable tooptionally disable auditing of remote access on either theclient or the server to avoid duplication.3.4.9. The Extended Attribute CacheNFS caching strategies are implementation specific, and arenot part of the NFS protocol. Caching is not required tosupport TNFS interoperability. This specification willtherefore not include specific details on the issue ofattribute caching. However, since the caching mechanismsare included in the NFS reference source code releases, andsince attribute caching is critical for achieving NFS per-formance goals, several suggestions are included in thissection.In most NFS client implementations, remote file attributesare cached on the client, improving performance and reducingnetwork traffic. The attribute cache is updated frequently,as most NFS procedures return file attributes along with_________________________ [9] This is the default policy; site specific audit-ing policies are established by the site security off-icer.TNFS-001.2.03 [Page 22]
INTERNET-DRAFT TNFS Protocol Specification July 06, 1992other requested information.A client side cache for the extended security file attri-butes should also be considered for similar reasons. Sinceall of the file's security attributes are returned with eachTNFS file access request, an extended security attributecache can now be maintained on the client.Extending the attribute validation procedure to includevalidating the security file attributes permits the completeset of file attributes to be checked and refreshed if theyare no longer valid. If the file's cached attributes arenot valid, a GETATTR procedure call can be made. The TNFSreply to this procedure now includes the complete set offile attribute information, permitting all of the file'scached attributes to be refreshed. Cached attribute entriesshall be aged and eventually flushed unless refreshed. Ifclient caching is enabled, then per process cached attributeentries shall be maintained.Note again that an attribute caching policy is not part ofthe protocol, and is an implementation technique used toimprove performance. During the window of time that thecache entry is valid, the client system applies the MLSaccess control policies on behalf of the server. It isrecommended that if an implementation supports the use ofclient side attribute caching, it shall also support amechanism for disabling the attribute cache. Specific imple-mentation details are provided in [4].4. Related Requirements and ExpectationsThis specification addresses extensions the NFS V2 protocolwhich accommodate network file access in a trusted, MLS net-work environment. Expectations for the environment forwhich 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 toTNFS-001.2.03 [Page 23]
INTERNET-DRAFT TNFS Protocol Specification July 06, 1992 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 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 note that client system auditing information will not be supplied for remote file access initiated from an unmodified NFS client; enabling server system auditing should be considered by the secu- rity officer to support these configurations 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_________________________ [10] Note that appropriate use of symbolic links onthe client will result in a client file name spacesimilar to one previously constructed by mounting sub-directories of exported server file trees.TNFS-001.2.03 [Page 24]
INTERNET-DRAFT TNFS Protocol Specification July 06, 1992 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] 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 IPSO [12] documents5. ConclusionThis document describes the set of extensions which supportnetwork file access in a network environment consisting ofMLS systems using the proposed TNFS protocol extensions._________________________ [11] Note that this information is needed by alltrusted network applications, and is not limited to NFSfile access.TNFS-001.2.03 [Page 25]
INTERNET-DRAFT TNFS Protocol Specification July 06, 1992Unmodified NFS clients and servers are supported using thede facto NFS V2 protocol.With the previously defined extensions, the MLS network fileaccess requirements are met. The extended structure defini-tions support the DAC and MAC attributes required for modi-fying or displaying the security attribute information. Theenhanced file open operation and the information labeladjustment policies are also supported.Thus, a small set of extensions to the NFS V2 environmentpermits MLS access control policies to be supported. Agree-ment on these changes will permit the current base of NFSclients and servers to be accommodated in the secureenvironment with no changes, and for TNFS modified systemsto interoperate using MLS policies.6. AcknowledgementsI would like to acknowledge the members of the ITEF/TSIG NFSSubcommittee, who were instrumental in evolving the MLSextended NFS Protocol Specification from the original propo-sal. Many comments were also made during the review of thelater drafts which greatly improved the specification's rea-dability. Contributing IETF TNFS working group membersinclude Jeff Edelheit, Fran Fadden, Jonathon Fraser, AliGohshan, Carl Smith, Mark Saake, Dave Summers, and CharlieWatt. I'd also like to acknowledge the contributions of theoriginal members of the TSIG Trusted NFS working group: inaddition 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 thesepersons as well, as a number of their comments are alsoreflected in the final version.7. Author's AddressFred GloverDigital Equipment Corporation110 Spit Brook Road ZK03-3/U14Nashua, New Hampshire 03062-2698Phone: 603-881-0388EMail: fglover@zk3.dec.com8. References[1] Sun Microsystems, Inc., "Network Filesystem Specifica- tion",RFC-1094, DDN Network Information Center, SRI International, Menlo Park, CA.TNFS-001.2.03 [Page 26]
INTERNET-DRAFT TNFS Protocol Specification July 06, 1992[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, "Compartmented Mode Workstation Evaluation Criteria", Defense Intelligence Agency, Washington, D.C., DIA document number DDS-2600-6243-91[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.[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 IP Security Option",RFC-1108, DDN Network Infor- mation Center, SRI International, Menlo Park, CA.[13] Postel, J., "User Datagram Protocol",RFC-768, DDN Network Information Center, SRI International, Menlo Park, CA.TNFS-001.2.03 [Page 27]
Datatracker
draft-ietf-tnfs-spec-01
This is an older version of an Internet-Draft whose latest revision state is "Expired".
| Document | Document type | This is an older version of an Internet-Draft whose latest revision state is "Expired". Expired & archived | |
|---|---|---|---|
| Select version | |||
| Compare versions | |||
| Author | |||
| RFC stream |   | ||
| Other formats | |||
| Additional resources | archive-server%40wdl1.wdl.loral.com |