Permissive mode vs. Enforcing mode

There will be times when you have run into difficulty and need to determine whether your problem stems from SELinux or not. For just this eventuality, SELinux includes the capability of setting its mode from enforcing to permissive and back again. Enforcing mode is just what it sounds like, a mode that allows SELinux to enforce policy access decisions. This is the standard operating mode of SELinux. Permissive mode, on the other hand, is a mode designed for development and troubleshooting. It will still check the security policy to see whether an attempted operation should be allowed, and log denials to the system logs, but it will not actually deny any operation.

To change into permissive mode, be sure you are logged in to the sysadm_r role (see my previous article for details). Issuing a setenforce 0 command will put the system into permissive mode, while a setenforce 1 command will return you to enforcing mode. To determine the current SELinux mode, use the getenforce command.

If you want to completely disable SELinux, you can pass selinux=0 to the kernel command line at startup, but this is not advisable since it disables SELinux entirely and any new files will not be labeled with the correct file context, forcing you to relabel when you re-enable SELinux. It's better to use permissive mode, and you can set your system to always start up in permissive mode by editing your /etc/selinux/config file.

File Context Labeling

SELinux file types are attched to each file on your SELinux system using extended file attributes. The use of these attributes is integral and required by SELinux, and has some system administration ramifications you should be aware of.

When formatting a new filesystem for use with SELinux, you must use a filesystem that supports these extended attributes. The ext2 and ext3 filesystems support extended attributes, and the xfs filesystem also is known to work, but reiserfs does not currently include extended attribute support.

When backing up files on an SELinux system, you need to use a backup method that is aware of and backs up these extended attributes. For example, the standard tar command will not back them up, so you need to use star as a substitute. star is an extension of the tar command, so you shouldn't run into serious problems here, but this could have ramifications with any backup scripts you may have written that call the tar command.

A common cause of SELinux problems is caused by mislabeled files. If you run into strange errors or see files that are mislabeled, the best, most reliable way of fixing them is to issue a touch /.autorelabel command followed by a reboot. This will trigger a relabel upon startup of the system, before files are opened and services are started. The restorecon command can also be used to restore files to their proper context, but it won't change the running context of processes that were launched by a mislabeled binary, so you may still run into problems.

The chcon command can be used to change the context of a file, but if the file has a default context set in the policy it will be reset to that default if the entire filesystem is relabeled. chcon is most useful for testing new file contexts before making a change permanent in the policy, if your system depends on contexts set using chcon you may run into trouble if you ever need to perform a global relabeling.

Finally, it is important to be aware of the differences between copying and moving files using the cp or mv commands. When moving a file using mv, the destination file will retain its original context. When copying a file using cp, the file will inherit a new context based on the destination directory it was copied to. This is an important distinction that can result in trouble if it is overlooked.

Policy Booleans

Policy booleans are sections of policy that can be switched on or off, providing a basic level of policy configurability at runtime without requiring the recompilation of the entire security policy. For example, you might be running a webmail application on your server that requires the webserver process to be able to connect to your mail server ports and read mail files out of user's home directories. Rather than adding those permissions to the security policy where they would reduce security for those not running webmail, a policy developer would create a boolean that the local administrator could enable only if it is required. This helps maintain a high level of security and follows the principle of least privilege.

To view a list of the policy booleans in your running policy and their current states, use the sestatus command. This command will list your current enforcing mode and the enforcing mode from the /etc/selinux/config file among other information, and a list of all policy booleans and whether they are active or inactive.

You can view the current status of a single boolean by using the command getsebool and passing it the name of the boolean you want to view the state of. Booleans are set using the setsebool command, and passing it the name of the boolean you want to set followed by a 1 or 0 to set the boolean active or inactive respectively.

Some sample booleans from the EnGarde Secure Linux SELinux policy are httpd_webmail and user_ping. The httpd_webmail boolean is used for the exact situation used as an example above, while the user_ping boolean determines whether or not regular users are able to send ping packets over the network. Booleans can be as simple as a single allow statement, or can enable or disable large swathes of the policy depending on their purpose.

Our SELinux journey is almost done. Next time, we'll discuss policy development basics and see how we can troubleshoot policy denials and write new SELinux policy or modify existing policy to allow our SELinux system to get its jobs done while maintaining a high level of security. Until then, farewell and remember to stay secure.
--
Pax Dickinson has over ten years of experience in systems administration and software development on a wide variety of hardware and software platforms. He is currently employed by Guardian Digital as a systems programmer where he develops and implements security solutions using EnGarde Secure Linux. His experience includes UNIX and Windows systems engineering and support at Prudential Insurance, Guardian Life Insurance, Philips Electronics and a wide variety of small business consulting roles.