Arguably one of the hottest topics today in IT is security. Invariably, when it comes to Linux systems – unquestionably Security-Enhanced Linux is usually one of the topics discussed. These are some the topics I will discuss in this tip: What is SELinux and what can it really do for you? What are some of its limitations? Should you be enabling SELinux for the Linux distributions that you support? What's new and what is the best way to deploy SELinux?
Developed by the National Security Agency (NSA), SELinux was originally introduced to provide for mandatory access controls (through the use of Linux security modules). The implementation modifies the Linux kernel and actually enforces the security controls. First released under the GPL in 2000, it was actually merged into the baseline 2.6 kernel in August of 2003. Enabling SELinux helps reduce risk of harm to applications and other user programs. It helps prevent malicious or poorly written programs from doing harm to the overall system. It's important to understand that SELinux isn't actually a Linux distribution in its own right. It is now integrated into the 2.6 kernel – a feature of which is supported in many Linux distributions, but not all of them. The essence of SELinux is the access controls, integrity controls, role-based access controls (RBAC) and type enforcement architecture. In other words, it consists of the modified kernel, a core set of libraries, and utilities modified packages and a policy configuration.
What is SELinux really designed to do? This is an important question. More than anything, it is supposed to enforce the separation of data, based on the rules that you configure. That configuration will help prevent unwarranted processes from getting access to your data. In doing so, it can be used to segregate a single host system with different security requirements defined by system authorizations.
What distribution...
To continue reading for free, register below or login
To read more you must become a member of SearchEnterpriseLinux.com
s are supported? Many distributions have SELinux integrated within them, they just need to be turned on. Others can be integrated with installed optional packages; however, I would not use SELinux if it were not included in my distribution. Some supported distributions include Red HAT, Debian and Fedora. It's worth noting that SUSE and Slackware do not support SELinux.
What is the competition to SELinux?
Probably its main competitor is AppArmor (both are licensed under the GPL), with Novell SUSE being the biggest distributor. Novell introduced the product into its SUSE distribution after they acquired Immunix. What is AppArmor's most important asset? A simplicity that is missing from SELinux. You can actually create a profile with just a few clicks and it can be managed by the YaST control center. One fundamental technical difference is that AppArmor identifies file system objects by path instead of inode.
What's new? Here are some of the highlights which were part of the last release in June of 2008
- New support for user and role remapping. This is for libsepol and is required for use in optionals.
- Dedicated role dominance in checkpolicy
- New support for policy capabilities in libsepol and checkpolicy
- Reduced memory usage by libsemanage and libsepol
- New avg_open interface in libselinux
Do I need SELinux?
I will say that I know many system administrators who after enabling the product, watch all their applications die a quick death. Implementing SELinux is a project. Do not minimize the work it will take to get your applications to run in this environment. If you are running in a production environment, I strongly suggest that you have a dedicated SELinux systems administrator fully trained in the intricacies of the system. Do not turn this on and expect everything to work the way it did before, or with only minor tweaking. If you do this, I can assure you that you will be looking for a job shortly. As important as security is in today's world it takes a back-seat to availability. SLA's usually require systems to be up 24x7 and users do not want to hear about security glitches.
What is the best way to implement SELinux?
The method that I've used successfully, has been ensuring that you have multiple environments. This includes; a sandbox, a development and a Q/A or a preproduction environment. In this scenario, first the team would get SELinux working in a sandbox environment. This box might have some basic applications loaded on it, but IT (e.g., system administrators) would be the owners. I cannot stress enough the importance of having this kind of environment. Why is this so important? Because your system administrators can play in the sandbox to their hearts content, meaning they can break the system without any impact. At the point in time where IT has learned enough about the system and has made some core applications work with SELinux, then you would go through the environment cycle, similar to how one may deploy OS patches or application releases. The development environment is usually owned by the developers. While they may not be thrilled with the fact that you want to tighten their box, if deployment of SELinux is a corporate policy, they won't have much choice about working with you.
After you've gotten the applications working in the sandbox then you can move on to Q/A or pre-production. After stringent testing – and I would include unit/system and UAT testing in this mix – move on to production. Unit/system testing refers to basic system functionality testing while user acceptance testing (UAT) involved actual users banging on the system to ensure core functionality. As you can see, this is no small endeavor, but it is a must when deploying such systems.
In conclusion, while I would certainly recommend that you have strong security polices in place. I would be very careful before making the call to deploy something like SELinux. While a successfully deployment is very achievable, you will need to treat this deployment like a real project. The time you spend in properly deploying it will pay back tenfold in improved application availability and user acceptance of security.
ABOUT THE AUTHOR: Ken Milberg is a systems consultant with two decades of experience working with Unix and Linux systems. He is a SearchEnterpriseLinux.com Ask the Experts advisor and columnist.
