LinuxSecurity.com
Share your story
The central voice for Linux and Open Source security news
Home News Topics Advisories HOWTOs Features Newsletters About Register

Welcome!
Sign up!
EnGarde Community
Login
Polls
What is the most important Linux security technology?
 
Advisories
Community
Linux Events
Linux User Groups
Link to Us
Security Center
Book Reviews
Security Dictionary
Security Tips
SELinux
White Papers
Featured Blogs
All About Linux
DanWalsh LiveJournal
Securitydistro
Latest Newsletters
Linux Security Week: October 27th, 2014
Linux Advisory Watch: October 24th, 2014
Subscribe
LinuxSecurity Newsletters
E-mail:
Choose Lists:
About our Newsletters
RSS Feeds
Get the LinuxSecurity news you want faster with RSS
Powered By

  
Hacks From Pax: SELinux Administration Print E-mail
User Rating:      How can I rate this item?
Posted by Pax Dickinson   
SELinux 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.

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.

Comments
Written by user on 2006-06-28 06:41:16
Great work on this article, I'm still having trouble locating documentation pertraining to every boolean and it's exact role, if anyone got a link I'd be very grateful, thanks.

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

Powered by AkoComment!

 
< Prev   Next >
    
Partner

 

Latest Features
Peter Smith Releases Linux Network Security Online
Securing a Linux Web Server
Password guessing with Medusa 2.0
Password guessing as an attack vector
Squid and Digest Authentication
Squid and Basic Authentication
Demystifying the Chinese Hacking Industry: Earning 6 Million a Night
Free Online security course (LearnSIA) - A Call for Help
What You Need to Know About Linux Rootkits
Review: A Practical Guide to Fedora and Red Hat Enterprise Linux - Fifth Edition
Yesterday's Edition
Hackers Are Using Gmail Drafts to Update Their Malware and Steal Data
Hackers target unclassified White House network
BYOD: Why the biggest security worry is the fool within rather than the enemy without
Partner Sponsor

Community | HOWTOs | Blogs | Features | Book Reviews | Networking
 Security Projects |  Latest News |  Newsletters |  SELinux |  Privacy |  Home
 Hardening |   About Us |   Advertise |   Legal Notice |   RSS |   Guardian Digital
(c)Copyright 2014 Guardian Digital, Inc. All rights reserved.