Installing security-enhanced Linux ---------------------------------- Execute these instructions from the slinux directory. 1) Edit policy/users for your users. This file defines each user recognized by the system security policy. It specifies the authorized roles for each user. Be sure to authorize at least one user for the system administrator role (sysadm_r). Other users can be limited to the ordinary user role (user_r). Remove the example users provided in the distributed users file (jadmin and jdoe). 2) Copy the example files from doc/context_examples into /etc/security and edit them for your site. Each file is described below. The default_context file defines the default login security context for each user. A security context has the syntax user:role:domain or user:role:type, e.g. root:sysadm_r:sysadm_t or root:user_r:user_t. The default_type file defines the default type (domain) for each role. Each entry has the syntax role:domain, e.g. sysadm_r:sysadm_t or user_r:user_t. The cron_context file defines the security context used by crond for cron jobs. This file also has the same format as the default_context file. An entry must be provided for the system user (system_u), e.g. system_u:system_r:system_crond_t. This entry is used for system cron jobs. Regular users should use a derived domain, e.g. root:sysadm_r:sysadm_crond_t or root:user_r:user_crond_t, so that the policy configuration can grant different permissions to user cron jobs than to interactive user sessions. The rsh_context file defines the security context used by rshd for each user. This file has the same format as the default_context file. Currently, all of the entries in this file should be of the form username:user_t:user_t, e.g. root:user_r:user_t. The rshd daemon is not allowed to transition to the administrator domain by the example security policy configuration, since it does not authenticate the user in any reliable manner. The ftp_context file defines the security context used by ftpd for ftp sessions. This file also has the same format as the default_context file. Entries should use a derived domain, e.g. root:sysadm_r:sysadm_ftpd_t or root:user_r:user_ftpd_t, so that the policy configuration can grant different permissions to user ftp sessions than to user login sessions. (Since the modified wu-ftpd has not been carefully tested yet, it is not installed by the installation scripts. This file will only be used if you manually build and install the modified wu-ftpd). We plan on eliminating the need for these separate context configuration files in the future. 3) Build the modified kernel, the kernel modules, the checkpolicy program and the initial policy. ./tools/build-kernel 4) Build the modified utilities. ./tools/build-apps 5) Install. su ./tools/install-kernel ./tools/install-apps 6) Configure your boot manager to boot the new security-enhanced Linux kernel. If you use the LILO boot manager, you can accomplish this configuration as follows: First, add an entry for the new kernel to /etc/lilo.conf. You can determine the name of the new kernel by looking in /boot. The new kernel's name will end in "-FLASK" (example: "vmlinuz-2.2.12-FLASK"). Do not use an initrd= option with the new entry. Retain an entry for your original kernel so that you can boot it from the lilo prompt if necessary. Finally, run /sbin/lilo. 7) If you were using a previous version of the security-enhanced Linux, remove any existing persistent label mappings. These mappings are stored in the ...security subdirectory in the root directory of each file system. For example, if your system had a root file system and two other file systems mounted at /boot and /home, you would do: rm -rf /...security /boot/...security /home/...security Although this invalidates any existing file labels, it does not clear the persistent SID values in the inodes. Consequently, some warnings are likely when the file system is relabeled in step 12. A program will be provided in the future to clear the persistent SID values. 8) Ensure that your current configuration is not set up to run the X Display Manager (xdm). The default runlevel specified in /etc/inittab should be runlevel 3 (Full multiuser mode), not runlevel 5 (X11). xdm and its helper programs have not yet been modified to set the security context for the user session. Consequently, you should not enable xdm on your Security-Enhanced Linux system. Domains have been defined for the X server, and we have successfully run X via startx after a normal login. However, these domains require certain permissions that are highly privileged. The X server still requires study to determine how to support it in a secure fashion. 9) Reboot. Boot the security-enhanced Linux kernel. At this point, your system is running the security-enhanced Linux kernel, but your file systems are not yet properly labeled, so processes are not yet separated into their corresponding domains. 10) Login in the sysadm_r role and sysadm_t domain. 11) Edit policy/file_contexts for your site. Check the pathnames against your file system layout. Some of the pathnames found in policy/file_contexts may not correspond to actual pathnames that exist on your system. You may wish to remove these non-existent pathnames from policy/file_contexts. However, if you leave some of these non-existent pathnames in policy/file_contexts, you will see warnings in the next step, but the system will still operate correctly. 12) Relabel the file systems. cd policy su make relabel 13) Build and install the normal policy. make install 14) Reboot. Boot the security-enhanced Linux kernel. At this point, your system is running the security-enhanced Linux kernel and your file systems are labeled, so processes should be placed automatically into appropriate domains. 15) Login in the sysadm_r role and sysadm_t domain again. 16) Add /usr/flask/bin and /usr/flask/sbin at the beginning of your path. 17) Try 'ps -e --context'. The second column should show the security context of each process. As mentioned above, a security context has the syntax user:role:domain or user:role:type. System processes should have the system_u user identity and the system_r role. Each system process with a different executable should have its own separate domain. If some system processes are running in the initrc_t domain, then either we have not moved it into a separate domain yet or the pathname for the executable in policy/file_contexts is not correct. Your user processes should have your user identity and the sysadm_r role. Your shell and most of its children will have the sysadm_t domain. Some of the processes that you run may be in different domains because they require different privileges. 18) Try 'ls --context /'. The fourth column should show the security context of each file or directory in /. Initially, the system_u user identity is used for all files at installation time. When you create new files after installation, they will be assigned the user identity of the creating process. The object_r role is used for all files, because roles are not relevant for files. Files with different protection requirements will have different types, e.g. /boot has the boot_t type and /etc has the etc_t type. 19) If you left CONFIG_FLASK_DEVELOP enabled when you configured and built the kernel, then your kernel is a development kernel. This kernel configuration option enables a mode for the development of Flask controls and security policies where permission denials are audited but not enforced. This mode should not be used in an operational system. It is intended to be used while developing the system in order to determine the permissions required for the system to operate. Each permission is only audited once per cache entry when in this mode so that subsequent denials of the same permission do not produce an unending stream of audit messages. When in this mode, the avc_toggle program may be used to toggle the kernel between being permissive and enforcing permissions. 20) Read the documents in doc/kernel and doc/policy.