Creating SELinux Policies Simplified
Modern Linux distributions ship with a plethora of security features and tools, and one of the most important features added to the kernel has been the inclusion of SELinux.
SELinux solves one the most challenging problems in security. How to control trusted users or processes. Trusted users, such as root in the *nix domain, have unlimited and unrestricted access to a system. They should have, as this account is supposed to be used only by the system administrator; however, this leads to a problem. What happens if the root account itself gets hacked, leaving the hacker with complete control of the system. Malicious users are not the only problem; misconfiguration of a security tool, such as iptables, can have a profound effect as well. Besides this, imagine a security vulnerability is discovered for a service you deployed on your server, and no patch is made available in a timely manner. In this case, your system is vulnerable. SELinux secures Linux systems from these sorts of security issues by implementing mandatory access controls (MACs) in the Linux kernel. SELinux is based on the Flask security architecture. Discussion of the Flask architecture is avoided in this article, as excellent documentation about it is easily available on the Internet.
To understand mandatory access control, we must go through the currently deployed security model called discretionary access control (DAC). In a DAC system, access to objects is restricted based on their classifications. This type of control is discretionary in the sense that a subject with a certain set of access permissions is capable of passing those permissions on to another subject. For example, any program you run while logged on as a certain user has the same access rights that you have. Rights are set by another user (for example, root).
Any particular permission (read, write, execute and so on) can be thought of as a two-dimensional graph with users on one axis and objects on another. In essence, DAC systems check the validity of credentials presented to them against stored information.
As mentioned, the SELinux security model is mandatory access control, or MAC. This controls access in a different manner. Whereas DAC security models are authentication-based, MAC systems rely on authorization, not only of users but also of each object loaded by the system.
A MAC system controls objects individually and makes decisions on the rights and/or permissions of objects based on a security policy, which can define what rights the object should be accorded, based on different variables.
An example of how discretionary versus mandatory access control styles could affect the operation of a computer is a Python script. If the script allows an external entity to insert and execute malicious code on a computer system under a DAC system, the malicious code now has the same access rights as the code that executed it—the Python script.
A MAC system can restrict the rights of a certain process to only the resources needed for normal operation. A Python script may create a process (or it may be forbidden), but that process might not have the same set of permissions as the process that created it. Thus, the MAC approach is seen as secure.
In SELinux, the security policy configuration is defined in a text file written in the m4 language. It is compiled when the security policy is finalized and, at boot time, loaded into the memory. Only the security server can make policy decisions on the permissions of an object.
Security policy enforcement is done by components called object managers, which receive requests from client objects, submit queries to the security server and enforce the resulting decisions.
The SELinux implementation of the security server uses a combination of two security paradigms, called Type Enforcement (TE) and Role-Based Access Control (RBAC).
Type Enforcement makes security decisions based on what kind of object requests the permissions. For example, object types could include a regular file, a directory, a process or a socket. Type enforcement is an object labeling system that, combined with access mapping (from the domain of the object requesting permission and to the type of the object requested), returns a decision that defines the permissible actions of the object.
Role-based access control assigns permissions to objects in a computer system based on the role they play within that system. In practice, this means a process would have its permissions based on its parent process, the user logged on at the time and any number of other variables.
How processes, filesystem objects and sockets communicate with each other is defined by the security policy. In particular, the security policy governs how different types and roles may interact, along with any specific rules.
At present, SELinux provides binary compatibility with existing applications and source compatibility with kernel modules. The current implementation of SELinux is x86-specific.
|Using Salt Stack and Vagrant for Drupal Development||May 20, 2013|
|Making Linux and Android Get Along (It's Not as Hard as It Sounds)||May 16, 2013|
|Drupal Is a Framework: Why Everyone Needs to Understand This||May 15, 2013|
|Home, My Backup Data Center||May 13, 2013|
|Non-Linux FOSS: Seashore||May 10, 2013|
|Trying to Tame the Tablet||May 08, 2013|
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- RSS Feeds
- New Products
- Using Salt Stack and Vagrant for Drupal Development
- Drupal Is a Framework: Why Everyone Needs to Understand This
- A Topic for Discussion - Open Source Feature-Richness?
- Home, My Backup Data Center
- Validate an E-Mail Address with PHP, the Right Way
- New Products
- Readers' Choice Awards
- Ahh, the Koolaid.
5 hours 31 min ago
- git-annex assistant
11 hours 30 min ago
- direct cable connection
11 hours 53 min ago
- Agreed on AirDroid. With my
12 hours 3 min ago
- I just learned this
12 hours 7 min ago
12 hours 37 min ago
- not living upto the mobile revolution
15 hours 29 min ago
- Deceptive Advertising and
16 hours 4 min ago
- Let\'s declare that you have
16 hours 5 min ago
- Alterations in Contest Due
16 hours 6 min ago
Free Webinar: Linux Backup and Recovery
Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.
In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.