Linux.com

Hi, and welcome to the third in a series of articles on Security Enhanced Linux. My first SELinux article detailed the background of SELinux, while my second article in the series discussed how SELinux makes access decisions. This week, I'll talk about how an SELinux system differs from a standard Linux system in terms of administration. Most of what you already know about Linux system administration will still apply to an SELinux system, but there are some additions and changes that are critical to understand when using SELinux.

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.

Read Entire Article:
http://www.linuxsecurity.com/content/view/120700/49/

Share    Print    Comments