| Managing Confined ServicesIn Red Hat Enterprise Linux, the samba package provides the Samba server. Run rpm -q samba to see if the samba package is installed. If it is not installed and you want to use Samba, run the following command as the root user to install it: yum install samba When SELinux is enabled, the Samba server (smbd) runs confined by default. Confined services run in their own domains, and are separated from other confined services. The following example demonstrates the smbd process running in its own domain. This example assumes the samba package is installed: Run getenforce to confirm SELinux is running in enforcing mode: $ getenforceEnforcing The getenforce command returns Enforcing when SELinux is running in enforcing mode. Run service smbd start as the root user to start smbd: service smb startStarting SMB services: [ OK ] Run ps -eZ | grep smb to view the smbd processes: $ ps -eZ | grep smbunconfined_u:system_r:smbd_t:s0 16420 ? 00:00:00 smbdunconfined_u:system_r:smbd_t:s0 16422 ? 00:00:00 smbd The SELinux context associated with the smbd processes is unconfined_u:system_r:smbd_t:s0. The second last part of the context, smbd_t, is the type. A type defines a domain for processes and a type for files. In this case, the smbd processes are running in the smbd_t domain.
Files must be labeled correctly to allow smbd to access and share them. For example, smbd can read and write to files labeled with the samba_share_t type, but by default, can not access files labeled with the httpd_sys_content_t type, which is intended for use by the Apache HTTP Server. Booleans must be turned on to allow certain behavior, such as allowing home directories and NFS file systems to be exported through Samba, as well as to allow Samba to act as a domain controller. Label files with the samba_share_t type to allow Samba to share them. Only label files you have created, and do not relabel system files with the samba_share_t type: Booleans can be turned on to share such files and directories. SELinux allows Samba to write to files labeled with the samba_share_t type, as long as /etc/samba/smb.conf and Linux permissions are set accordingly. The samba_etc_t type is used on certain files in /etc/samba/, such as smb.conf. Do not manually label files with the samba_etc_t type. If files in /etc/samba/ are not labeled correctly, run restorecon -R -v /etc/samba as the root user to restore such files to their default contexts. If /etc/samba/smb.conf is not labeled with the samba_etc_t type, the service smb start command may fail and an SELinux denial may be logged. The following is an example denial when /etc/samba/smb.conf was labeled with the httpd_sys_content_t type: setroubleshoot: SELinux is preventing smbd (smbd_t) "read" to ./smb.conf (httpd_sys_content_t). For complete SELinux messages. run sealert -l deb33473-1069-482b-bb50-e4cd05ab18af SELinux is based on the least level of access required for a service to run. Services can be run in a variety of ways; therefore, you must tell SELinux how you are running services. The following Booleans allow you to tell SELinux how you are running Samba: allow_smbd_anon_writeHaving this Boolean enabled allows smbd to write to a public directory, such as an area reserved for common files that otherwise has no special access restrictions. samba_create_home_dirsHaving this Boolean enabled allows Samba to create new home directories independently. This is often done by mechanisms such as PAM. samba_domain_controllerWhen enabled, this Boolean allows Samba to act as a domain controller, as well as giving it permission to execute related commands such as useradd, groupadd and passwd. samba_enable_home_dirsEnabling this Boolean allows Samba to share users' home directories. samba_export_all_roExport any file or directory, allowing read-only permissions. This allows files and directories that are not labeled with the samba_share_t type to be shared through Samba. When the samba_export_all_ro Boolean is on, but the samba_export_all_rw Boolean is off, write access to Samba shares is denied, even if write access is configured in /etc/samba/smb.conf, as well as Linux permissions allowing write access. samba_export_all_rwExport any file or directory, allowing read and write permissions. This allows files and directories that are not labeled with the samba_share_t type to be exported through Samba. Permissions in /etc/samba/smb.conf and Linux permissions must be configured to allow write access. samba_run_unconfinedHaving this Boolean enabled allows Samba to run unconfined scripts in the /var/lib/samba/scripts directory. samba_share_fusefsThis Boolean must be enabled for Samba to share fusefs file systems. samba_share_nfsDisabling this Boolean prevents smbd from having full access to NFS shares via Samba. Enabling this Boolean will allow Samba to share NFS file systems. use_samba_home_dirsEnable this Boolean to use a remote server for Samba home directories. virt_use_sambaAllow virtual machine access to CIFS files.
4.4. Configuration examplesThe following examples provide real-world demonstrations of how SELinux complements the Samba server and how full function of the Samba server can be maintained. 4.4.1. Sharing directories you createThe following example creates a new directory, and shares that directory through Samba: Run rpm -q samba samba-common samba-client to confirm the samba, samba-common, and samba-client packages are installed. If any of these packages are not installed, install them by running yum install package-name as the root user. Run mkdir /myshare as the root user to create a new top-level directory to share files through Samba. Run touch /myshare/file1 as the root user to create an empty file. This file is used later to verify the Samba share mounted correctly. SELinux allows Samba to read and write to files labeled with the samba_share_t type, as long as /etc/samba/smb.conf and Linux permissions are set accordingly. Run the following command as the root user to add the label change to file-context configuration: semanage fcontext -a -t samba_share_t "/myshare(/.*)?" Run restorecon -R -v /myshare as the root user to apply the label changes: # restorecon -R -v /mysharerestorecon reset /myshare context unconfined_u:object_r:default_t:s0->system_u:object_r:samba_share_t:s0restorecon reset /myshare/file1 context unconfined_u:object_r:default_t:s0->system_u:object_r:samba_share_t:s0 Edit /etc/samba/smb.conf as the root user. Add the following to the bottom of this file to share the /myshare/ directory through Samba: [myshare]comment = My sharepath = /mysharepublic = yeswriteable = no A Samba account is required to mount a Samba file system. Run smbpasswd -a username as the root user to create a Samba account, where username is an existing Linux user. For example, smbpasswd -a testuser creates a Samba account for the Linux testuser user: # smbpasswd -a testuserNew SMB password: Enter a passwordRetype new SMB password: Enter the same password againAdded user testuser. Running smbpasswd -a username, where username is the username of a Linux account that does not exist on the system, causes a Cannot locate Unix account for 'username'! error. Run service smb start as the root user to start the Samba service: service smb startStarting SMB services: [ OK ] Run smbclient -U username -L localhost to list the available shares, where username is the Samba account added in step 7. When prompted for a password, enter the password assigned to the Samba account in step 7 (version numbers may differ): $ smbclient -U username -L localhostEnter username's password:Domain=[HOSTNAME] OS=[Unix] Server=[Samba 3.4.0-0.41.el6]Sharename Type Comment--------- ---- -------myshare Disk My shareIPC$ IPC IPC Service (Samba Server Version 3.4.0-0.41.el6)username Disk Home DirectoriesDomain=[HOSTNAME] OS=[Unix] Server=[Samba 3.4.0-0.41.el6]Server Comment--------- -------Workgroup Master--------- ------- Run mkdir /test/ as the root user to create a new directory. This directory will be used to mount the myshare Samba share. Run the following command as the root user to mount the myshare Samba share to /test/, replacing username with the username from step 7: mount //localhost/myshare /test/ -o user=username Enter the password for username, which was configured in step 7. Run ls /test/ to view the file1 file created in step 3: $ ls /test/file1
It may not be possible to label files with the samba_share_t type, for example, when wanting to share a website in /var/www/html/. For these cases, use the samba_export_all_ro Boolean to share any file or directory (regardless of the current label), allowing read only permissions, or the samba_export_all_rw Boolean to share any file or directory (regardless of the current label), allowing read and write permissions. The following example creates a file for a website in /var/www/html/, and then shares that file through Samba, allowing read and write permissions. This example assumes the httpd, samba, samba-common, samba-client, and wget packages are installed: As the root user, create a /var/www/html/file1.html file. Copy and paste the following content into /var/www/html/file1.html: <html><h2>File being shared through the Apache HTTP Server and Samba.</h2></html> Run ls -Z /var/www/html/file1.html to view the SELinux context of file1.html: $ ls -Z /var/www/html/file1.html-rw-r--r--. root root unconfined_u:object_r:httpd_sys_content_t:s0 /var/www/html/file1.html file1.index.html is labeled with the httpd_sys_content_t. By default, the Apache HTTP Server can access this type, but Samba can not.
Run service httpd start as the root user to start the Apache HTTP Server: service httpd startStarting httpd: [ OK ] Change into a directory your user has write access to, and run the wget http://localhost/file1.html command. Unless there are changes to the default configuration, this command succeeds: $ wget http://localhost/file1.htmlResolving localhost... 127.0.0.1Connecting to localhost|127.0.0.1|:80... connected.HTTP request sent, awaiting response... 200 OKLength: 84 [text/html]Saving to: `file1.html.1'100%[=======================>] 84 --.-K/s in 0s `file1.html.1' saved [84/84] Edit /etc/samba/smb.conf as the root user. Add the following to the bottom of this file to share the /var/www/html/ directory through Samba: [website]comment = Sharing a websitepath = /var/www/html/public = nowriteable = no The /var/www/html/ directory is labeled with the httpd_sys_content_t type. By default, Samba can not access files and directories labeled with the httpd_sys_content_t type, even if Linux permissions allow it. To allow Samba access, run the following command as the root user to turn the samba_export_all_ro Boolean on: setsebool -P samba_export_all_ro on Do not use the -P option if you do not want the change to persist across reboots. Note: turning the samba_export_all_ro Boolean on allows Samba to access any type. Run service smb start as the root user to start smbd: service smb startStarting SMB services: [ OK ]
Chapter 5. File Transfer ProtocolFile Transfer Protocol (FTP) is one of the oldest and most commonly used protocols found on the Internet today. Its purpose is to reliably transfer files between computer hosts on a network without requiring the user to log directly into the remote host or have knowledge of how to use the remote system. It allows users to access files on remote systems using a standard set of simple commands. The Very Secure FTP Daemon (vsftpd) is designed from the ground up to be fast, stable, and, most importantly, secure. Its ability to handle large numbers of connections efficiently and securely is why vsftpd is the only stand-alone FTP distributed with Red Hat Enterprise Linux. In Red Hat Enterprise Linux, the vsftpd package provides the Very Secure FTP daemon. Run rpm -q vsftpd to see if vsftpd is installed: $ rpm -q vsftpd If you want an FTP server and the vsftpd package is not installed, run the following command as the root user to install it: yum install vsftpd The vsftpd FTP daemon runs confined by default. SELinux policy defines how vsftpd interacts with files, processes, and with the system in general. For example, when an authenticated user logs in via FTP, they can not read from or write to files in their home directories: SELinux prevents vsftpd from accessing user home directories by default. Also, by default, vsftpd does not have access to NFS or CIFS file systems, and anonymous users do not have write access, even if such write access is configured in /etc/vsftpd/vsftpd.conf. Booleans can be turned on to allow the previously mentioned access. The following example demonstrates an authenticated user logging in, and an SELinux denial when trying to view files in their home directory: Run rpm -q ftp to see if the ftp package is installed. If it is not, run yum install ftp as the root user to install it. Run rpm -q vsftpd to see if the vsftpd package is installed. If it is not, run yum install vsftpd as the root user to install it. In Red Hat Enterprise Linux, vsftpd only allows anonymous users to log in by default. To allow authenticated users to log in, edit /etc/vsftpd/vsftpd.conf as the root user. Make sure the local_enable=YES option is uncommented: # Uncomment this to allow local users to log in.local_enable=YES Run service vsftpd start as the root user to start vsftpd. If the service was running before editing vsftpd.conf, run service vsftpd restart as the root user to apply the configuration changes: service vsftpd startStarting vsftpd for vsftpd: [ OK ] Run ftp localhost as the user you are currently logged in with. When prompted for your name, make sure your username is displayed. If the correct username is displayed, press Enter, otherwise, enter the correct username: $ ftp localhostConnected to localhost (127.0.0.1).220 (vsFTPd 2.1.0)Name (localhost:username):331 Please specify the password.Password: Enter your password500 OOPS: cannot change directory:/home/usernameLogin failed.ftp> An SELinux denial similar to the following is logged: setroubleshoot: SELinux is preventing the ftp daemon from reading users home directories (username). For complete SELinux messages. run sealert -l c366e889-2553-4c16-b73f-92f36a1730ce Access to home directories has been denied by SELinux. This can be fixed by activating the ftp_home_dir Boolean. Enable this ftp_home_dir Boolean by running the following command as the root user: # setsebool -P ftp_home_dir=1 Do not use the -P option if you do not want changes to persist across reboots. Try to log in again. Now that SELinux is allowing access to home directories via the ftp_home_dir Boolean, logging in will succeed.
By default, anonymous users have read access to files in /var/ftp/ when they log in via FTP. This directory is labeled with the public_content_t type, allowing only read access, even if write access is configured in /etc/vsftpd/vsftpd.conf. The public_content_t type is accessible to other services, such as Apache HTTP Server, Samba, and NFS. Use one of the following types to share files through FTP: public_content_tLabel files and directories you have created with the public_content_t type to share them read-only through vsftpd. Other services, such as Apache HTTP Server, Samba, and NFS, also have access to files labeled with this type. Files labeled with the public_content_t type can not be written to, even if Linux permissions allow write access. If you require write access, use the public_content_rw_t type. public_content_rw_tLabel files and directories you have created with the public_content_rw_t type to share them with read and write permissions through vsftpd. Other services, such as Apache HTTP Server, Samba, and NFS, also have access to files labeled with this type. Remember that Booleans for each service must be turned on before they can write to files labeled with this type.
SELinux is based on the least level of access required for a service to run. Services can be run in a variety of ways; therefore, you must tell SELinux how you are running services. The following Booleans allow you to tell SELinux how you are running vsftpd: allow_ftpd_anon_writeWhen disabled, this Boolean prevents vsftpd from writing to files and directories labeled with the public_content_rw_t type. Turn this Boolean on to allow users to upload files via FTP. The directory where files are uploaded to must be labeled with the public_content_rw_t type and Linux permissions set accordingly. allow_ftpd_full_accessWhen this Boolean is on, only Linux (DAC) permissions are used to control access, and authenticated users can read and write to files that are not labeled with the public_content_t or public_content_rw_t types. allow_ftpd_use_cifsHaving this Boolean enabled allows vsftpd to access files and directories labeled with the cifs_t type; therefore, having this Boolean enabled allows you to share file systems mounted via Samba through vsftpd. allow_ftpd_use_nfsHaving this Boolean enabled allows vsftpd to access files and directories labeled with the nfs_t type; therefore, having this Boolean enabled allows you to share file systems mounted via NFS through vsftpd. ftp_home_dirHaving this Boolean enabled allows authenticated users to read and write to files in their home directories. When this Boolean is off, attempting to download a file from a home directory results in an error such as 550 Failed to open file. An SELinux denial is logged. ftpd_connect_dbAllow FTP daemons to initiate a connection to a database. httpd_enable_ftp_serverAllow httpd to listen on the FTP port and act as a FTP server. tftp_anon_writeHaving this Boolean enabled allows TFTP access to a public directory, such as an area reserved for common files that otherwise has no special access restrictions.
5.4. Configuration Examples5.4.1. Uploading to an FTP siteThe following example creates an FTP site that allows a dedicated user to upload files. It creates the directory structure and the required SELinux configuration changes: Run setsebool ftp_home_dir=1 as the root user to enable access to FTP home directories. Run mkdir -p /myftp/pub as the root user to create a new top-level directory. Set Linux permissions on the /myftp/pub/ directory to allow a Linux user write access. This example changes the owner and group from root to owner user1 and group root. Replace user1 with the user you want to give write access to: # chown user1:root /myftp/pub# chmod 775 /myftp/pub The chown command changes the owner and group permissions. The chmod command changes the mode, allowing the user1 user read, write, and execute permissions, and members of the root group read, write, and execute permissions. Everyone else has read and execute permissions: this is required to allow the Apache HTTP Server to read files from this directory. When running SELinux, files and directories must be labeled correctly to allow access. Setting Linux permissions is not enough. Files labeled with the public_content_t type allow them to be read by FTP, Apache HTTP Server, Samba, and rsync. Files labeled with the public_content_rw_t type can be written to by FTP. Other services, such as Samba, require Booleans to be set before they can write to files labeled with the public_content_rw_t type. Label the top-level directory (/myftp/) with the public_content_t type, to prevent copied or newly-created files under /myftp/ from being written to or modified by services. Run the following command as the root user to add the label change to file-context configuration: semanage fcontext -a -t public_content_t /myftp Run restorecon -R -v /myftp/ to apply the label change: # restorecon -R -v /myftp/restorecon reset /myftp context unconfined_u:object_r:default_t:s0->system_u:object_r:public_content_t:s0 Confirm /myftp is labeled with the public_content_t type, and /myftp/pub/ is labeled with the default_t type: $ ls -dZ /myftp/drwxr-xr-x. root root system_u:object_r:public_content_t:s0 /myftp/$ ls -dZ /myftp/pub/drwxrwxr-x. user1 root unconfined_u:object_r:default_t:s0 /myftp/pub/ FTP must be allowed to write to a directory before users can upload files via FTP. SELinux allows FTP to write to directories labeled with the public_content_rw_t type. This example uses /myftp/pub/ as the directory FTP can write to. Run the following command as the root user to add the label change to file-context configuration: semanage fcontext -a -t public_content_rw_t "/myftp/pub(/.*)?" Run restorecon -R -v /myftp/pub as the root user to apply the label change: # restorecon -R -v /myftp/pubrestorecon reset /myftp/pub context system_u:object_r:default_t:s0->system_u:object_r:public_content_rw_t:s0 The allow_ftpd_anon_write Boolean must be on to allow vsftpd to write to files that are labeled with the public_content_rw_t type. Run the following command as the root user to turn this Boolean on: setsebool -P allow_ftpd_anon_write on Do not use the -P option if you do not want changes to persist across reboots.
The following example demonstrates logging in via FTP and uploading a file. This example uses the user1 user from the previous example, where user1 is the dedicated owner of the /myftp/pub/ directory: Run cd ~/ to change into your home directory. Then, run mkdir myftp to create a directory to store files to upload via FTP. Run cd ~/myftp to change into the ~/myftp/ directory. In this directory, create an ftpupload file. Copy the following contents into this file: File upload via FTP from a home directory. Run getsebool allow_ftpd_anon_write to confirm the allow_ftpd_anon_write Boolean is on: $ getsebool allow_ftpd_anon_writeallow_ftpd_anon_write --> on If this Boolean is off, run setsebool -P allow_ftpd_anon_write on as the root user to turn it on. Do not use the -P option if you do not want the change to persist across reboots. Run service vsftpd start as the root user to start vsftpd: # service vsftpd startStarting vsftpd for vsftpd: [ OK ] Run ftp localhost. When prompted for a username, enter the username of the user who has write access, then, enter the correct password for that user: $ ftp localhostConnected to localhost (127.0.0.1).220 (vsFTPd 2.1.0)Name (localhost:username):331 Please specify the password.Password: Enter the correct password230 Login successful.Remote system type is UNIX.Using binary mode to transfer files.ftp> cd myftp250 Directory successfully changed.ftp> put ftpupload local: ftpupload remote: ftpupload227 Entering Passive Mode (127,0,0,1,241,41).150 Ok to send data.226 File receive OK.ftp> 221 Goodbye. The upload succeeds as the allow_ftpd_anon_write Boolean is enabled.
Chapter 6. Network File SystemNFS (Network File System) allows hosts to mount partitions on a remote system and use them as though they are local file systems. This allows the system administrator to store resources in a central location on the network, providing authorized users continuous access to them. In Red Hat Enterprise Linux, the nfs-utils package is required for full NFS support. Run rpm -q nfs-utils to see if the nfs-utils is installed. If it is not installed and you want to use NFS, run the following command as the root user to install it: yum install nfs-utils When running SELinux, the NFS daemons are confined by default. SELinux policy allows NFS to share files by default. By default, mounted NFS file systems on the client side are labeled with a default context defined by policy for NFS file systems. In common policies, this default context uses the nfs_t type.The following types are used with NFS. Different types allow you to configure flexible access: var_lib_nfs_tThis type is used for existing and new files copied to or created in the /var/lib/nfs directory. This type should not need to be changed in normal operation. To restore changes to the default settings, run the restorecon -R -v /var/lib/nfs command as the root user. nfsd_exec_tThe /usr/sbin/rpc.nfsd file is labeled with the nfsd_exec_t, as are other system executables and libraries related to NFS. Users should not label any files with this type. nfsd_exec_t will transition to nfsd_t.
SELinux is based on the least level of access required for a service to run. Services can be run in a variety of ways; therefore, you must tell SELinux how you are running services. The following Booleans allow you to tell SELinux how you are running NFS: allow_ftpd_use_nfsWhen enabled, this Boolean allows ftpd access to NFS mounts. allow_nfsd_anon_writeWhen enabled, this Boolean allows nfsd to write to a public directory anonymously; such as to an area reserved for common files that otherwise has no special access restrictions. httpd_use_nfsWhen enabled, this Boolean will allow httpd to access files stored on a NFS filesystem. nfs_export_all_roExport any file or directory via NFS, allowing read-only permissions. nfs_export_all_rwExport any file or directory via NFS, allowing read and write permissions. qemu_use_nfsAllow qemu to use NFS file systems. samba_share_nfsWhen disabled, this Boolean prevents smbd from having full access to NFS shares via Samba. Enabling this Boolean will allow Samba to share NFS file systems. use_nfs_home_dirsHaving this Boolean enabled adds support for NFS home directories. virt_use_nfsAllow virtual machine access to NFS files. xen_use_nfsAllow Xen to use NFS files.
6.4. Configuration Examples6.4.1. Sharing directories using NFSThe example in this section creates a directory and shares it using NFS and SELinux. Two hosts are used in this example; a NFS server with a hostname of nfs-srv with an IP address of 192.168.1.1, and a client with a hostname of nfs-client and an IP address of 192.168.1.100. Both hosts are on the same subnet (192.168.1.0/24). This is an example only and assumes that the nfs-utils package is installed, that the SELinux targeted policy is used, and that SELinux is running in enforced mode. This example will show that while even with full network availability and Linux file permissions granting access to all users via NFS, SELinux is still able to block mounting of NFS file systems unless the proper permissions are given via SELinux Booleans. Steps 1-10 in the following procedure should be performed on the NFS server, nfs-srv. Run the setsebool command to disable read/write mounting of NFS file systems: setsebool -P nfs_export_all_rw off Do not use the -P option if you do not want setsebool changes to persist across reboots. Run rpm -q nfs-utils to confirm the nfs-utils package is installed. The nfs-utils package provides support programs for using NFS and should be installed on a NFS server and on any clients in use. If this package is not installed, install it by running yum install nfs-utils as the root user. Run mkdir /myshare as the root user to create a new top-level directory to share using NFS. Run touch /myshare/file1 as the root user to create a new empty file in the shared area. This file will be accessed later by the client. To show that SELinux is still able to block access even when Linux permissions are completely open, give the /myshare directory full Linux access rights for all users: # chmod -R 777 /myshare This is an example only and these permissions should not be used in a production system. Edit the /etc/exports file and add the following line to the top of the file: /myshare 192.168.1.100(rw) This entry shows the full path on the server to the shared folder /myshare, the host or network range that nfs-srv will share to (in this case the IP address of a single host, nfs-client at 192.168.1.100), and finally the share permissions. Read and write permissions are given here, as indicated by (rw). The TCP and UDP ports used for NFS are assigned dynamically by rpcbind, which can cause problems when creating firewall rules. To simplify the process of allowing NFS traffic through the firewall in this example, edit the /etc/sysconfig/nfs file and uncomment the MOUNTD_PORT,STATD_PORT,LOCKD_TCPPORT and LOCKD_UDPPORT variables. Changing the port numbers in this file is not required for this example. Ensure that incoming connections are allowed through the server's firewall. This can be done via the system-config-firewall tool: TCP and UDP port 2049 for NFS. TCP and UDP port 111 (rpcbind/sunrpc). The TCP and UDP port specified by the MOUNTD_PORT="port" option. The TCP and UDP port specified by the STATD_PORT="port" option. The TCP port specified by the LOCKD_TCPPORT="port" option. The UDP port specified by the LOCKD_UDPPORT="port" option.
Run service nfs start as the root user to start NFS and its related services: # service nfs startStarting NFS services:[ OK ]Starting NFS quotas:[ OK ]Starting NFS daemon:[ OK ]Starting NFS mountd:[ OK ] To ensure that the NFS subsystem export table is updated, run exportfs -rv as the root user: # exportfs -rvexporting 192.168.1.100:/myshare Run showmount -e as the root user to show all exported file systems: # showmount -eExport list for nfs-srv:/myshare 192.168.1.100
At this point the server nfs-srv has been configured to allow NFS communications to nfs-client at 192.168.1.100, and full Linux file systems permissions are active. If SELinux were disabled, the client would be able to mount this share and have full access over it. However, as the nfs_export_all_rw Boolean is disabled, the client is currently not able to mount this file system, as shown in the following output. This step should be performed on the client, nfs-client: [nfs-client]# mkdir /myshare[nfs-client]# mount.nfs 192.168.1.1:/myshare /mysharemount.nfs: access denied by server while mounting 192.168.1.1:/myshare/ Enable the SELinux Boolean that was disabled in Step 1 above, and the client will be able to successfully mount the shared file system. This step should be performed on the NFS server, nfs-srv: [nfs-srv]# setsebool -P nfs_export_all_rw on Restart the NFS daemon: [nfs-srv]# service nfs restart Now try to mount the NFS file system again. This step should be performed on the NFS client, nfs-client: [nfs-client]# mount.nfs 192.168.1.1:/myshare /myshare[nfs-client]#[nfs-client]# ls /mysharetotal 0-rwxrwxrwx. 1 root root 0 2009-04-16 12:07 file1[nfs-client]# The file system has been mounted successfully by the client. This example demonstrates how SELinux adds another layer of protection and can still enforce SELinux permissions even when Linux permissions are set to give full rights to all users. Chapter 7. Berkeley Internet Name DomainBIND performs name resolution services via the named daemon. BIND lets users locate computer resources and services by name instead of numerical addresses. In Red Hat Enterprise Linux, the bind package provides a DNS server. Run rpm -q bind to see if the bind package is installed. If it is not installed, run the following command as the root user to install it: yum install bind The default permissions on the /var/named/slaves,/var/named/dynamic and /var/named/data directories allow zone files to be updated via zone transfers and dynamic DNS updates. Files in /var/named are labeled with the named_zone_t type, which is used for master zone files. For a slave server, configure /etc/named.conf to place slave zones in /var/named/slaves. The following is an example of a domain entry in /etc/named.conf for a slave DNS server that stores the zone file for testdomain.com in /var/named/slaves: zone "testdomain.com" {type slave;masters { IP-address; };file "/var/named/slaves/db.testdomain.com"; };If a zone file is labeled named_zone_t, the named_write_master_zones Boolean must be enabled to allow zone transfers and dynamic DNS to update the zone file. Also, the mode of the parent directory has to be changed to allow the named user or group read, write and execue access. If zone files in /var/named/ are labeled with named_cache_t type, a file system relabel or running restorecon -R /var/ will change their type to named_zone_t. The following types are used with BIND. Different types allow you to configure flexible access: named_zone_tUsed for master zone files. Other services can not modify files of this type. named can only modify files of this type if the named_write_master_zones Boolean is turned on. named_cache_tBy default, named can write to files labeled with this type, without additional Booleans being set. Files copied or created in the /var/named/slaves,/var/named/dynamic and /var/named/data directories are automatically labeled with the named_cache_t type. named_var_run_tFiles copied or created in the /var/run/bind/, /var/run/named/, and /var/run/unbound/ directories are automatically labeled with the named_var_run_t type. named_conf_tBIND-related configuration files (usually stored in the /etc/ directory) are automatically labeled with the named_conf_t type. named_exec_tBIND-related executable files (usually stored in the /usr/sbin/ directory) are automatically labeled with the named_exec_t type. named_log_tBIND-related log files (usually stored in the /var/log/ directory) are automatically labeled with the named_log_t type. named_initrc_exec_tExecutable BIND-related files in the /etc/rc.d/init.d/ directory are automatically labeled with the named_initrc_exec_t type.
SELinux is based on the least level of access required for a service to run. Services can be run in a variety of ways; therefore, you must tell SELinux how you are running services. The following Booleans allow you to tell SELinux how you are running NFS: named_write_master_zonesWhen disabled, this Boolean prevents named from writing to zone files or directories labeled with the named_zone_t type. named does not usually need to write to zone files; but in the case that it needs to, or if a secondary server needs to write to zone files, enable this Boolean to allow this action.
7.4. Configuration ExamplesBIND allows hosts to update their records in DNS and zone files dynamically. This is used when a host computer's IP address changes frequently and the DNS record requires real-time modification. Use the /var/named/dynamic directory for zone files you want updated via dynamic DNS. Files created in or copied into /var/named/dynamic inherit Linux permissions that allow named to write to them. As such files are labeled with the named_cache_t type, SELinux allows named to write to them. If a zone file in /var/named/dynamic is labeled with the named_zone_t type, dynamic DNS updates may not be successful for a certain period of time as the update needs to be written to a journal first before being merged. If the zone file is labeled with the named_zone_t type when the journal attempts to be merged, an error such as the following is logged: named[PID]: dumping master file: rename: /var/named/dynamic/zone-name: permission denied Also, the following SELinux denial is logged: setroubleshoot: SELinux is preventing named (named_t) "unlink" to zone-name (named_zone_t) To resolve this labeling issue, run the restorecon -R -v /var/named/dynamic command as the Linux root user. Chapter 8. Concurrent Versioning SystemThe Concurrent Versioning System (CVS) is a free revision-control system. It is used to monitor and keep track of modifications to a central set of files which are usually accessed by several different users. It is commonly used by programmers to manage a source code repository and is widely used by open source programmers. In Red Hat Enterprise Linux, the cvs package provides CVS. Run rpm -q cvs to see if the cvs package is installed. If it is not installed and you want to use CVS, run the following command as the root user to install it: yum install cvs The cvs daemon runs as cvs_t. By default in Red Hat Enterprise Linux, CVS is only allowed to read and write certain directories. The label cvs_data_t defines which areas the cvs daemon has read and write access to. When using CVS with SELinux, assigning the correct label is essential for clients to have full access to the area reserved for CVS data. The following types are used with CVS. Different types allow you to configure flexible access: cvs_data_tThis type is used for data in a CVS repository. CVS can only gain full access to data if it has this type. cvs_exec_tThis type is used for the /usr/bin/cvs binary.
SELinux is based on the least level of access required for a service to run. Services can be run in a variety of ways; therefore, you must tell SELinux how you are running services. The following Boolean allows you to tell SELinux how you are running CVS: allow_cvs_read_shadowThis Boolean allows the cvs daemon to access the /etc/shadow file for user authentication.
8.4. Configuration ExamplesThis example describes a simple CVS setup and an SELinux configuration which allows remote access. Two hosts are used in this example; a CVS server with a hostname of cvs-srv with an IP address of 192.168.1.1 and a client with a hostname of cvs-client and an IP address of 192.168.1.100. Both hosts are on the same subnet (192.168.1.0/24). This is an example only and assumes that the cvs and xinetd packages are installed, that the SELinux targeted policy is used, and that SELinux is running in enforced mode. This example will show that even with full DAC permissions, SELinux can still enforce policy rules based on file labels and only allow access to certain areas that have been specifically labeled for access by CVS. Steps 1-9 should be performed on the CVS server, cvs-srv. This example requires the cvs and xinetd packages. Run rpm -q cvs to see if the cvs package is installed. If it is not installed, run the following command as the root user to install cvs: # yum install cvs Run rpm -q xinetd to see if the xinetd package is installed. If it is not installed, run the following command as the root user to install xinetd: # yum install xinetd Create a group named CVS. This can be done via the groupadd CVS command as the root user, or by using the system-config-users tool. Create a user with a username of cvsuser and make this user a member of the CVS group. This can be done using the system-config-users tool. Edit the /etc/services file and make sure that the CVS server has uncommented entries looking similar to the following: cvspserver2401/tcp# CVS client/server operationscvspserver2401/udp# CVS client/server operations Create the CVS repository in the root area of the file system. When using SELinux, it is best to have the repository in the root file system so that recursive labels can be given to it without affecting any other subdirectories. For example, as the root user, create a /cvs directory to house the repository: [root@cvs-srv]# mkdir /cvs Give full permissions to the /cvs directory to all users: [root@cvs-srv]# chmod -R 777 /cvs This is an example only and these permissions should not be used in a production system. Edit the /etc/xinetd.d/cvs file and make sure that the CVS section is uncommented and configured to use the /cvs directory. The file should look similar to: service cvspserver{disable= noport= 2401socket_type= streamprotocol= tcpwait= nouser= rootpassenv= PATHserver= /usr/bin/cvsenv= HOME=/cvsserver_args= -f --allow-root=/cvs pserver#bind= 127.0.0.1Start the xinetd daemon by running service xinetd start as the root user. Add a rule which allows inbound connections using TCP on port 2401 by using the system-config-firewall tool. As the cvsuser user, run the following command: [cvsuser@cvs-client]$ cvs -d /cvs init At this point, CVS has been configured but SELinux will still deny logins and file access. To demonstrate this, set the $CVSROOT variable on cvs-client and try to log in remotely. The following step should be performed on cvs-client: [cvsuser@cvs-client]$ export CVSROOT=:pserver:[email protected]:/cvs[cvsuser@cvs-client]$[cvsuser@cvs-client]$ cvs loginLogging in to :pserver:[email protected]:2401/cvsCVS password: ********cvs [login aborted]: unrecognized auth response from 192.168.100.1: cvs pserver: cannot open /cvs/CVSROOT/config: Permission denied SELinux has blocked access. In order to get SELinux to allow this access, the following step should be performed on cvs-srv: Change the context of the /cvs directory as the root user in order to recursively label any existing and new data in the /cvs directory, giving it the cvs_data_t type: [root@cvs-srv]# semanage fcontext -a -t cvs_data_t '/cvs(/.*)?'[root@cvs-srv]# restorecon -R -v /cvs The client, cvs-client should now be able to log in and access all CVS resources in this repository: [cvsuser@cvs-client]$ export CVSROOT=:pserver:[email protected]:/cvs[cvsuser@cvs-client]$[cvsuser@cvs-client]$ cvs loginLogging in to :pserver:[email protected]:2401/cvsCVS password: ********[cvsuser@cvs-client]$
Chapter 9. Squid Caching Proxy"Squid is a caching proxy for the Web supporting HTTP, HTTPS, FTP, and more. It reduces bandwidth and improves response times by caching and reusing frequently-requested web pages. Squid has extensive access controls and makes a great server accelerator." In Red Hat Enterprise Linux, the squid package provides the Squid Caching Proxy. Run rpm -q squid to see if the squid package is installed. If it is not installed and you want to use squid, run the following command as the root user to install it: # yum install squid 9.1. Squid Caching Proxy and SELinuxWhen SELinux is enabled, squid runs confined by default. Confined processes run in their own domains, and are separated from other confined processes. If a confined process is compromised by an attacker, depending on SELinux policy configuration, an attacker's access to resources and the possible damage they can do is limited. The following example demonstrates the squid processes running in their own domain. This example assumes the squid package is installed: Run getenforce to confirm SELinux is running in enforcing mode: $ getenforceEnforcing The getenforce command returns Enforcing when SELinux is running in enforcing mode. Run service squid start as the root user to start squid: # service squid startStarting squid: [ OK ] Run ps -eZ | grep squid to view the squid processes: $ ps -eZ | grep squidunconfined_u:system_r:squid_t:s0 2522 ? 00:00:00 squidunconfined_u:system_r:squid_t:s0 2524 ? 00:00:00 squidunconfined_u:system_r:squid_t:s0 2526 ? 00:00:00 ncsa_authunconfined_u:system_r:squid_t:s0 2527 ? 00:00:00 ncsa_authunconfined_u:system_r:squid_t:s0 2528 ? 00:00:00 ncsa_authunconfined_u:system_r:squid_t:s0 2529 ? 00:00:00 ncsa_authunconfined_u:system_r:squid_t:s0 2530 ? 00:00:00 ncsa_authunconfined_u:system_r:squid_t:s0 2531 ? 00:00:00 unlinkd The SELinux context associated with the squid processes is unconfined_u:system_r:squid_t:s0. The second last part of the context, squid_t, is the type. A type defines a domain for processes and a type for files. In this case, the squid processes are running in the squid_t domain.
SELinux policy defines how processes running in confined domains, such as squid_t, interact with files, other processes, and the system in general. Files must be labeled correctly to allow squid access to them. When /etc/squid/squid.conf is configured so squid listens on a port other than the default TCP ports 3128, 3401 or 4827, the semanage port command must be used to add the required port number to the SELinux policy configuration. The following example demonstrates configuring squid to listen on a port that is not initially defined in SELinux policy configuration for squid, and, as a consequence, squid failing to start. This example also demonstrates how to then configure the SELinux system to allow squid to successfully listen on a non-standard port that is not already defined in the policy. This example assumes the squid package is installed. Run each command in the example as the root user: Run service squid status to confirm squid is not running: # service squid statussquid is stopped If the output differs, run service squid stop to stop the process: # service squid stopStopping squid: [ OK ] Run semanage port -l | grep -w squid_port_t to view the ports SELinux allows squid to listen on: semanage port -l | grep -w -i squid_port_tsquid_port_t tcp 3401, 4827squid_port_t udp 3401, 4827 Edit /etc/squid/squid.conf as the root user. Configure the http_port option so it lists a port that is not configured in SELinux policy configuration for squid. In this example, squid is configured to listen on port 10000: # Squid normally listens to port 3128http_port 10000 Run the setsebool command to make sure the squid_connect_any Boolean is set to off. This ensures squid is only permitted to operate on specific ports: setsebool -P squid_connect_any 0 Run service squid start to start squid: # service squid startStarting squid: .................... [FAILED] An SELinux denial similar to the following is logged: localhost setroubleshoot: SELinux is preventing the squid (squid_t) from binding to port 10000. For complete SELinux messages. run sealert -l 97136444-4497-4fff-a7a7-c4d8442db982 For SELinux to allow squid to listen on port 10000, as used in this example, the following command is required: # semanage port -a -t squid_port_t -p tcp 10000 Run service squid start again to start squid and have it listen on the new port: # service squid startStarting squid: [ OK ] Now that SELinux has been configured to allow squid to listen on a non-standard port (TCP 10000 in this example), squid starts successfully on this port.
Type Enforcement is the main permission control used in SELinux targeted policy. All files and processes are labeled with a type: types define a domain for processes and a type for files. SELinux policy rules define how types access each other, whether it be a domain accessing a type, or a domain accessing another domain. Access is only allowed if a specific SELinux policy rule exists that allows it. The following types are used with squid. Different types allow you to configure flexible access: httpd_squid_script_exec_tThis type is used for utilities such as cachemgr.cgi, which provides a variety of statistics about squid and its configuration. squid_cache_tUse this type for data that is cached by squid, as defined by the cache_dir directive in /etc/squid/squid.conf. By default, files created in or copied into /var/cache/squid and /var/spool/squid are labeled with the squid_cache_t type. Files for the squidGuard URL redirector plugin for squid created in or copied to /var/squidGuard are also labeled with the squid_cache_t type. Squid is only able to use files and directories that are labeled with this type for its cached data. squid_conf_tThis type is used for the directories and files that squid uses for its configuration. Existing files, or those created in or copied to /etc/squid and /usr/share/squid are labeled with this type, including error messages and icons. squid_exec_tThis type is used for the squid binary, /usr/sbin/squid. squid_log_tThis type is used for logs. Existing files, or those created in or copied to /var/log/squid or /var/log/squidGuard must be labeled with this type. squid_initrc_exec_tThis type is used for the initialization file required to start squid which is located at /etc/rc.d/init.d/squid. squid_var_run_tThis type is used by files in /var/run, especially the process id (PID) named /var/run/squid.pid which is created by squid when it runs.
SELinux is based on the least level of access required for a service to run. Services can be run in a variety of ways; therefore, you must tell SELinux how you are running services. The following Boolean allows you to tell SELinux how you are running Squid: squid_connect_anyWhen enabled, this Boolean permits squid to initiate a connection to a remote host on any port.
9.4. Configuration Examples9.4.1. Squid Connecting to Non-Standard PortsThe following example provides a real-world demonstration of how SELinux complements Squid by enforcing the above Boolean and by default only allowing access to certain ports. This example will then demonstrate how to change the Boolean and show that access is then allowed. Note that this is an example only and demonstrates how SELinux can affect a simple configuration of Squid. Comprehensive documentation of Squid is beyond the scope of this document. Refer to the official Squid documentation for further details. This example assumes that the Squid host has two network interfaces, Internet access, and that any firewall has been configured to allow access on the internal interface using the default TCP port on which Squid listens (TCP 3128). As the root user, install the squid package. Run rpm -q squid to see if the squid package is installed. If it is not installed, run yum install squid as the root user to install it. Edit the main configuration file, /etc/squid/squid.conf and confirm that the cache_dir directive is uncommented and looks similar to the following: cache_dir ufs /var/spool/squid 100 16 256 This line specifies the default settings for the cache_dir directive to be used in this example; it consists of the Squid storage format (ufs), the directory on the system where the cache resides (/var/spool/squid), the amount of disk space in megabytes to be used for the cache (100), and finally the number of first-level and second-level cache directories to be created (16 and 256 respectively). In the same configuration file, make sure the http_access allow localnet directive is uncommented. This allows traffic from the localnet ACL which is automatically configured in a default installation of Squid on Red Hat Enterprise Linux. It will allow client machines on any existing RFC1918 network to have access through the proxy, which is sufficient for this simple example. In the same configuration file, make sure the visible_hostname directive is uncommented and is configured to the hostname of the machine. The value should be the fully qualified domain name (FQDN) of the host: visible_hostname squid.example.com As the root user, run service squid start to start squid. As this is the first time squid has started, this command will initialise the cache directories as specified above in the cache_dir directive and will then start the squid daemon. The output is as follows if squid starts successfully: # /sbin/service squid startinit_cache_dir /var/spool/squid... Starting squid: . [ OK ] Confirm that the squid process ID (PID) has started as a confined service, as seen here by the squid_var_run_t value: # ls -lZ /var/run/squid.pid -rw-r--r--. root squid unconfined_u:object_r:squid_var_run_t:s0 /var/run/squid.pid At this point, a client machine connected to the localnet ACL configured earlier is successfully able to use the internal interface of this host as its proxy. This can be configured in the settings for all common web browsers, or system-wide. Squid is now listening on the default port of the target machine (TCP 3128), but the target machine will only allow outgoing connections to other services on the Internet via common ports. This is a policy defined by SELinux itself. SELinux will deny access to non-standard ports, as shown in the next step: When a client makes a request using a non-standard port through the Squid proxy such as a website listening on TCP port 10000, a denial similar to the following is logged: SELinux is preventing the squid daemon from connecting to network port 10000 To allow this access, the squid_connect_any Boolean must be modified, as it is disabled by default. To turn the squid_connect_any Boolean on, run the following command as the root user: # setsebool -P squid_connect_any on Do not use the -P option if you do not want setsebool changes to persist across reboots. The client will now be able to access non-standard ports on the Internet as Squid is now permitted to initiate connections to any port, on behalf of its clients.
|
| |
