Earn an NSA recognized IA Masters Online

The NSA has designated Norwich University a center of Academic Excellence in Information Security. Our program offers unparalleled Infosec management education and the case study affords you unmatched consulting experience. Using interactive e-Learning technology, you can earn this esteemed degree, without disrupting your career or home life.

http://www.msia.norwich.edu/linsec

SELinux Administration
Pax Dickinson

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/

LinuxSecurity.com Feature Extras:

Linux File & Directory Permissions Mistakes - One common mistake Linux administrators make is having file and directory permissions that are far too liberal and allow access beyond that which is needed for proper system operations. A full explanation of unix file permissions is beyond the scope of this article, so I'll assume you are familiar with the usage of such tools as chmod, chown, and chgrp. If you'd like a refresher, one is available right here on linuxsecurity.com.

Introduction: Buffer Overflow Vulnerabilities - Buffer overflows are a leading type of security vulnerability. This paper explains what a buffer overflow is, how it can be exploited, and what countermeasures can be taken to prevent the use of buffer overflow vulnerabilities.

Getting to Know Linux Security: File Permissions - Welcome to the first tutorial in the 'Getting to Know Linux Security' series. The topic explored is Linux file permissions. It offers an easy to follow explanation of how to read permissions, and how to set them using chmod. This guide is intended for users new to Linux security, therefore very simple. If the feedback is good, I'll consider creating more complex guides for advanced users. Please let us know what you think and how these can be improved.

 

Take advantage of our Linux Security discussion list! This mailing list is for general security-related questions and comments. To subscribe send an e-mail to security-discuss-request@linuxsecurity.com with "subscribe" as the subject.

Thank you for reading the LinuxSecurity.com weekly security newsletter. The purpose of this document is to provide our readers with a quick summary of each week's most relevant Linux security headline.

Only registered users can write comments.
Please login or register.

Powered by AkoComment!