（RHCA）Red Hat Enterprise Linux RHS333: Red Hat Enterprise Security: Network Services

Unit 6

Network File System

Objectives

Upon completion of this unit, you should be able to: Review NFS protocol and vulnerabilities Understand how to configure NFSv4 servers and clients Use Kerberos to secure NFS authentication and traffic Investigate how SELinux and NFS interact Troubleshoot NFS configuration problems

Service Profile: NFS

Type: System V-launched service Packages: nfs-utils Daemons: nfsd, rpc.mountd, rpc.statd, lockd, rpc.idmapd, rpc.gssd, rpc.svcgssd Scripts: nfs, nfslock, rpcidmapd, rpcgssd, rpcsvcgssd Ports: 2049/tcp and 2049/udp (nfsd), others semi-random (found through portmap (111/tcp and 111/udp)) Configuration: /etc/exports, /etc/sysconfig/nfs, /etc/idmapd.conf Related: portmap, krb5-workstation, util-linux

History of NFS

nfs mount type NFSv2: original UDP-based public release NFSv3: added safe async exports, TCP support, 64-bit file sizes, larger read and write sizes, some implementations support Kerberos features nfs4 mount type NFSv4: integrated auxiliary protocols, UTF-8 file names, improved user mapping support, improved locking, improved client caching, all implementations support Kerberos features

Mounting and Using an NFSv3 File System

Client asks server's portmap for its rpc.mountd port Client asks server's rpc.mountd for permission to mount exported file system rpc.mountd issues client an initial file handle to file system Client uses the initial file handle to access and change the file system through server's nfsd service File locks are managed by lockd and rpc.statd services

AUTH_SYS and User Authentication

A program tries to access a file on a mounted NFS file system NFS client includes the program's UID and GID numbers in the NFS request for file access sent to the server NFS server trusts the client to send accurate UID/GID information Assumes same user to UID / group to GID mappings on server and clients NFS server uses the UID/GID information to control access

Controlling AUTH_SYS Name Mappings

Use centralized authentication when possible Use central NIS or LDAP service to keep UID and GID mappings identical on server and its NFS clients Use appropriate options in /etc/exports root_squash maps UID and GID 0 to UID and GID 65534 all_squash maps all UIDs and GIDs to 65534

Basic Export Security

Do not export directories containing server configuration files Export entire file system or consider using subtree_check Do not export with no_root_squash unless necessary Carefully use crossmnt or nohide to export file systems mounted on an export

Vulnerabilities of NFSv3

Auxiliary protocols use random ports, complicating firewall configuration Clients are authenticated by hostname or IP address Server trusts clients to authenticate users Cleartext protocol is subject to tampering and eavesdropping Complex services run as root

Using Static Ports with NFSv3

Simplify firewall configuration by setting static ports for auxiliary NFS services nfsd uses TCP and UDP port 2049 by default Edit /etc/sysconfig/nfs: LOCKD_TCPPORT=888 LOCKD_UDPPORT=888 MOUNTD_PORT=889            STATD_PORT= 12001 Verify ports with rpcinfo -p

Using NFSv4

Simplify firewall configuration by using NFSv4 Eliminates auxiliary RPC services Only need access to server's port 2049 (and 111) rpc.idmapd must run on client and server Can run but do not need rpc.mountd, rpc.statd, or lockd Requires changes in how file systems are exported "Root pseudo-filesystem" approach

The NFSv4 Pseudo-Filesystem

Server Presentation

An NFSv4 server provides all its exports as a single tree The fsid=0 export option is used to export one file system as / This export is the "root pseudo-filesystem" Other file systems to export must be mounted as subdirectories of the root pseudo-filesystem Each child file system needs its own entry in /etc/exports Export the root pseudo-filesystem with the crossmnt option "Bind mounts" can be used in /etc/fstab to set up the tree /var/ftp /export/ftp none bind 0 0

The NFSv4 Pseudo-Filesystem

Client Access

NFSv4 mounts are relative to the root pseudo-filesystem Must specify -t nfs4 option to mount using NFSv4 If /export on the server is the root pseudo-filesystem, it is mounted as / mount -t nfs4 server1.example.com:/ /home/server1 Do not need to mount child exports individually May browse for them under root pseudo-filesystem May choose to mount them in other locations instead

RPCSEC_GSS

RPC Security using GSSAPI

Uses GSSAPI to secure RPC protocols RPCSEC_GSS replaces AUTH_SYS Used with Kerberos 5 to secure RPC Can be used to secure NFSv3 or NFSv4 exports With NFSv4, removes need for identical UID and GID mappings Additional supporting daemons needed rpc.svcgssd must run on the NFS server rpc.gssd must run on the NFS client

RPCSEC_GSS NFS Export Security

Export using a special pseudo-hostname in /etc/exports: gss/krb5 requires ticket-based machine and user authentication Client must specify sec=krb5 mount option gss/krb5i requires integrity checking via secure checksums Client must specify sec=krb5i mount option gss/krb5p requires privacy via data encryption Client must specify sec=krb5p mount option Currently can not combine Kerberos requirements with IP address or hostname-based restrictions

Example: A Kerberized NFSv4 Server

Need Kerberos principals in /etc/krb5.keytab host/server102.example.com nfs/server102.example.com (DES-CBC-MD5:normal only) Configure /etc/exports /export gss/krb5p(rw,crossmnt,fsid=0) Uncomment SECURE_NFS="yes" in /etc/sysconfig/nfs Run service nfs restart; service rpcidmapd restart

Example: A Kerberized NFS Client

Need Kerberos principals in /etc/krb5.keytab host/station2.example.com nfs/station2.example.com (DES-CBC-MD5:normal only) Uncomment SECURE_NFS="yes" in /etc/sysconfig/nfs Run service rpcgssd start; service rpcidmapd restart Mount, specifying security mode (and nfs4 if desired) NFSv3: mount -o rw,sec=krb5p server102:/export /mnt NFSv4: mount -t nfs4 -o rw,sec=krb5p server102:/ /mnt

SELinux and NFS

Server can not provide file contexts to clients Clients label all files system_u:object_r:nfs_t:s0 by default Clients can override with context= mount option Server maintains local contexts on its exported file system normally Booleans control exports and use of NFS nfs_export_all_ro / nfs_export_all_rw use_nfs_home_dirs

Troubleshooting NFS

Stale file handle errors NFS server (nfsd) is down or unreachable NFS server no longer exports to you NFSv3 mount used sec=sys when a Kerberos mode is required fsid mismatch after NFS failover in HA cluster Possible SELinux issues Server: A boolean is set to block exports Client: The confined service is not allowed to use type nfs_t

Troubleshooting NFS and AUTH_SYS

Same file owned by different users on different machines Using NFS with sec=sys but UIDs/GIDs are not synchronized User on NFS client can access a file they do not own, and can not access files they do own Both username and UID may look wrong, but user can still access the file! Using NFSv4 with sec=sys but UIDs/GIDs are not synchronized User on NFS client accesses / creates files as user nfsnobody Does the export use the all_squash or root_squash option? NFSv4: Is rpc.idmapd stopped or misconfigured?

Troubleshooting Kerberized NFS

Ensure Kerberos infrastructure is working Does the host have correct principals in the keytab? Is rpc.svcgssd or rpc.gssd running? Does the user have a current TGT or has it expired? NFSv4: Is rpc.idmapd configured correctly?

End of Unit 6

Questions and Answers Summary Static ports or NFSv4 for simpler firewall management sec=krb5 for Kerberos-based machine and user authentication sec=krb5i for anti-tampering protection sec=krb5p for anti-eavesdropping protection SELinux and NFS Troubleshooting NFS