http://beginlinux.com/blog/2013/03/understanding-selinux
SELinux
A task of any operating system is to provide software that strongly increases its security. A lot of programs of this type have been created; some are better than others. What does it look like in terms of Linux? Of course, here we have many more choices when it comes to this type of software, but some software is worth recommending. Some people already know what I mean: SELinux. Why choose this solution? Why do I think it is so different from other software of this type? And the last key question: who really should use it? Despite the fact that SELinux uses the basic standards, it really is very revolutionary. This system, as the name suggests is Security
Enhanced Linux!
What is SELinux and where did it come from?
Do you want a book definition? Okay, no problem. SELinux is a system with MAC, or Mandatory Access Control. It implements a security policy called RBAC, Role-Based Access Control. This policy is implemented by DTAC, which is Dynamically Typed Access Control, which also translates as the domain name of Access Control System. True, it sounds a bit baffling. But in practice, it is really very simple. It is only the theory that seems highly complicated.
And now it’s time for something much simpler: a little bit about the history of SELinux All work on SELinux is sponsored by the U.S. National Security Agency. The money goes to the team that is working on SELinux, the Secure Computing Corp. It should be noted that this company also owns all of the patents for the software. The idea of SELinux, a product that we all know today, is not really new; it is 20 years old. In 1992, a new idea for security resulted in a project called Distributed Trusted Match. The project developed some innovative solutions, which became part of an operating system called Fluke. Fluke evolved into Flux, which led to the development of Flask architecture. The Flask architecture was then integrated with the Linux kernel, and the whole newly created project was called SELinux. How did this happen?
SELinux was the first security project in the history of scientists from NSA. NSA scientists were the first to have noticed that mainstream operating systems do not have a required critical security to enforce access control and separation of inside information on the requirements of consistency. The result is that most security mechanisms are vulnerable to manipulation and handling, which involves a cascade of consequences. The choice of Linux as a system for the NSA security project was not accidental.
Linux was chosen because of two main features:
• growing popularity
• open developement environment
NSA’s intention was to present a functionality that could succeed in mainstream operating systems and at the same time would have a chance to contribute to the improvement of the safety of commonly used operating systems. The project thate has been registered as SELinux resulted from several previous NSA projects.
The work of NSA scientists (meaning researchers sponsored by NSA) was not intended to solve existing problems of security and SELinux is in no way an attempt to improve security in Linux. Changes in Linux only covered the introduction of new mechanisms.
What is hiding in the middle of SELinux?
In fact, three elements of this system should attract our attention. The first is the kernel. At first, SELinux tried several kernels, but today the complete infrastructure of SELinux uses the Linux kernel. It is, of course, slightly modified and is called LSM, Linux Security Modules.This infrastructure provides all possible interfaces that allow you to fully control access to all system objects when they are initiated by user actions. These are, for example, opening a file, creating a new folder, or binding ports. How does it work? Well, SELinux simply connects to the interface and forces the use of the system’s own security policy. From the point of view of the administrator who installs SELinux, this system is simply a patch for the kernel.
The second element that I have to mention is that key programs are modified. How does it work in practice? In most cases, SELinux allows all programs a little bit of freedom. They do not need to understand that SELinux is not just Linux. But in any operating system there are some safety-critical software systems that must always be extended to support SELinux. These programs are primarily ssh, ls, ps, xdm, or login. And here again there is a role for the Linux. During installation or download, fully modified versions of these programs are required or security patches must be applied to the source programs to ensure the security of the system.
The third and last thing that distinguishes SELinux are its rules, or policy. What is their role? They define access rights, the right to pursue activities in the system, and the behavior of SELinux system. Although I mention them third, they are the most important. These rules determine the effective action of the system. A large part of this article will be devoted to writing the rules and the way they are constructed in the system. The truth is that system administrators never, under any circumstances, should be required to write their own rules for the policy, unless there are custom requirements.
However, every administrator should have the knowledge that will allow him to modify the rules to suit the system’s needs. In addition to knowing something and be able to use your knowledge, you need to understand all the rules that already exist in the operating system.
How to really grasp this thing called MAC?
As already mentioned, the system is a method of enforcing SELinux MAC. So let’s see exactly what it means to us as administrators. Well, I managed to find the main principle, applicable to all systems using MAC. In my opinion, it should be this: none of the users of the system has the right to decide in any way the security and rights of access to objects in the system. All of those rights and security should always be defined according to the security policy of the system. In the case of SELinux, they should be reflected in all policy records.
MAC policy alone is very often confused with ACL. The facts very quickly refute this myth. In fact, ACL does not carry MAC policy. These lists also have yet another disadvantage. In practice, they are very complicated in terms of configuration and maintaining correctness. You can also say that they are different is in terms of action. ACL always specifies individual use cases, while MAC always sets out general principles.
In fact, ACL support has been withdrawn from the Linux kernel version 2.4.x already Why did this happen? Because Linux kernel developers decided that ACLs are not really as good a way to control the powers and actions of the user in the operating system. Despite this, those lists are sometimes used. For example, if we have a Samba server, they are often used, because they allow you to set permissions for all the files from the Microsoft Windows client.
Another heavy shortcut, or DTAC
As I mentioned earlier, DTAC is Dynamically Typed Access Control, but it is often translated as the domain name of Access Control System. But that’s not what this section is about. Let’s focus on the real features of DTAC.
In the case of DTAC, each of the objects in the system, whether it is a directory, port, or any device, has its own unique type. What does this mean in practice? Some top-down rules are always forced on each object type . These rules in no way depend on the decision of the user, but the system administrator creates and controls the policy. This means that in any system that uses a DTAC, you can create any number of rules, a thousand or a million, and the system is always prepared.
In addition, the system has whole sets of rules on how to take action on all objects of each type. We will return to this subject later. In fact, in the case of DTAC, control and validation testing of all rules are much easier than in other cases. As a curiosity, I should mention that IBM has developed a tool, whose main task is to automatically check the consistency and accuracy of security policy DTAC.
Another heavy stand, the RBAC
As I mentioned earlier, RBAC stands for Role Based Access Control. We can recognize that this is an access control system based on user roles in the system. This term is not often used. Where can we find it? Well, any standard Unix or Linux system has built-in Role Based Access Control. And the truth is that if you look closely at the UNIX system, the roles are always split. There are always certain types of system users, each of whom is entitled to exercise a very limited range of activities. This means that each of them performs a role within the UNIX system.
There is another element that qualifies a standard UNIX system to become a system with built-in RBAC. There is something in them called SUID. As you all probably know, SUID can change the user’s role and the actions that can be performed by the user.
How does this all work with SELinux? Well, it really is a SELinux RBAC system with built-in rules that are implemented by DTAC. SELinux system also extends what is called the philosophy of SUID. Thus, it can also extend the understanding of the role of users in the system. To summarize quickly: a SELinux system is designed to allow for a much more flexible way, which is also more accurate and much better suited to your needs, to identify and help implement user roles within the system.
Summary
This is really only a quick introduction to SELinux. The article describes the basics of the mechanism used on a daily basis in this system. It still does not do anything special, but the desire to write a summary of what it is captivated me. On our website, with SELinux we often capture 50 fixes critical to the security system in a very short time, less than seven days. Another decisive advantage is its ease of use. As a Linux system administrator, I have never met a tool that uses such simple rules, yet describes so much. Yet very few administrators so far know the SELinux system.
SELinux
A task of any operating system is to provide software that strongly increases its security. A lot of programs of this type have been created; some are better than others. What does it look like in terms of Linux? Of course, here we have many more choices when it comes to this type of software, but some software is worth recommending. Some people already know what I mean: SELinux. Why choose this solution? Why do I think it is so different from other software of this type? And the last key question: who really should use it? Despite the fact that SELinux uses the basic standards, it really is very revolutionary. This system, as the name suggests is Security
Enhanced Linux!
What is SELinux and where did it come from?
Do you want a book definition? Okay, no problem. SELinux is a system with MAC, or Mandatory Access Control. It implements a security policy called RBAC, Role-Based Access Control. This policy is implemented by DTAC, which is Dynamically Typed Access Control, which also translates as the domain name of Access Control System. True, it sounds a bit baffling. But in practice, it is really very simple. It is only the theory that seems highly complicated.
And now it’s time for something much simpler: a little bit about the history of SELinux All work on SELinux is sponsored by the U.S. National Security Agency. The money goes to the team that is working on SELinux, the Secure Computing Corp. It should be noted that this company also owns all of the patents for the software. The idea of SELinux, a product that we all know today, is not really new; it is 20 years old. In 1992, a new idea for security resulted in a project called Distributed Trusted Match. The project developed some innovative solutions, which became part of an operating system called Fluke. Fluke evolved into Flux, which led to the development of Flask architecture. The Flask architecture was then integrated with the Linux kernel, and the whole newly created project was called SELinux. How did this happen?
SELinux was the first security project in the history of scientists from NSA. NSA scientists were the first to have noticed that mainstream operating systems do not have a required critical security to enforce access control and separation of inside information on the requirements of consistency. The result is that most security mechanisms are vulnerable to manipulation and handling, which involves a cascade of consequences. The choice of Linux as a system for the NSA security project was not accidental.
Linux was chosen because of two main features:
• growing popularity
• open developement environment
NSA’s intention was to present a functionality that could succeed in mainstream operating systems and at the same time would have a chance to contribute to the improvement of the safety of commonly used operating systems. The project thate has been registered as SELinux resulted from several previous NSA projects.
The work of NSA scientists (meaning researchers sponsored by NSA) was not intended to solve existing problems of security and SELinux is in no way an attempt to improve security in Linux. Changes in Linux only covered the introduction of new mechanisms.
What is hiding in the middle of SELinux?
In fact, three elements of this system should attract our attention. The first is the kernel. At first, SELinux tried several kernels, but today the complete infrastructure of SELinux uses the Linux kernel. It is, of course, slightly modified and is called LSM, Linux Security Modules.This infrastructure provides all possible interfaces that allow you to fully control access to all system objects when they are initiated by user actions. These are, for example, opening a file, creating a new folder, or binding ports. How does it work? Well, SELinux simply connects to the interface and forces the use of the system’s own security policy. From the point of view of the administrator who installs SELinux, this system is simply a patch for the kernel.
The second element that I have to mention is that key programs are modified. How does it work in practice? In most cases, SELinux allows all programs a little bit of freedom. They do not need to understand that SELinux is not just Linux. But in any operating system there are some safety-critical software systems that must always be extended to support SELinux. These programs are primarily ssh, ls, ps, xdm, or login. And here again there is a role for the Linux. During installation or download, fully modified versions of these programs are required or security patches must be applied to the source programs to ensure the security of the system.
The third and last thing that distinguishes SELinux are its rules, or policy. What is their role? They define access rights, the right to pursue activities in the system, and the behavior of SELinux system. Although I mention them third, they are the most important. These rules determine the effective action of the system. A large part of this article will be devoted to writing the rules and the way they are constructed in the system. The truth is that system administrators never, under any circumstances, should be required to write their own rules for the policy, unless there are custom requirements.
However, every administrator should have the knowledge that will allow him to modify the rules to suit the system’s needs. In addition to knowing something and be able to use your knowledge, you need to understand all the rules that already exist in the operating system.
How to really grasp this thing called MAC?
As already mentioned, the system is a method of enforcing SELinux MAC. So let’s see exactly what it means to us as administrators. Well, I managed to find the main principle, applicable to all systems using MAC. In my opinion, it should be this: none of the users of the system has the right to decide in any way the security and rights of access to objects in the system. All of those rights and security should always be defined according to the security policy of the system. In the case of SELinux, they should be reflected in all policy records.
MAC policy alone is very often confused with ACL. The facts very quickly refute this myth. In fact, ACL does not carry MAC policy. These lists also have yet another disadvantage. In practice, they are very complicated in terms of configuration and maintaining correctness. You can also say that they are different is in terms of action. ACL always specifies individual use cases, while MAC always sets out general principles.
In fact, ACL support has been withdrawn from the Linux kernel version 2.4.x already Why did this happen? Because Linux kernel developers decided that ACLs are not really as good a way to control the powers and actions of the user in the operating system. Despite this, those lists are sometimes used. For example, if we have a Samba server, they are often used, because they allow you to set permissions for all the files from the Microsoft Windows client.
Another heavy shortcut, or DTAC
As I mentioned earlier, DTAC is Dynamically Typed Access Control, but it is often translated as the domain name of Access Control System. But that’s not what this section is about. Let’s focus on the real features of DTAC.
In the case of DTAC, each of the objects in the system, whether it is a directory, port, or any device, has its own unique type. What does this mean in practice? Some top-down rules are always forced on each object type . These rules in no way depend on the decision of the user, but the system administrator creates and controls the policy. This means that in any system that uses a DTAC, you can create any number of rules, a thousand or a million, and the system is always prepared.
In addition, the system has whole sets of rules on how to take action on all objects of each type. We will return to this subject later. In fact, in the case of DTAC, control and validation testing of all rules are much easier than in other cases. As a curiosity, I should mention that IBM has developed a tool, whose main task is to automatically check the consistency and accuracy of security policy DTAC.
Another heavy stand, the RBAC
As I mentioned earlier, RBAC stands for Role Based Access Control. We can recognize that this is an access control system based on user roles in the system. This term is not often used. Where can we find it? Well, any standard Unix or Linux system has built-in Role Based Access Control. And the truth is that if you look closely at the UNIX system, the roles are always split. There are always certain types of system users, each of whom is entitled to exercise a very limited range of activities. This means that each of them performs a role within the UNIX system.
There is another element that qualifies a standard UNIX system to become a system with built-in RBAC. There is something in them called SUID. As you all probably know, SUID can change the user’s role and the actions that can be performed by the user.
How does this all work with SELinux? Well, it really is a SELinux RBAC system with built-in rules that are implemented by DTAC. SELinux system also extends what is called the philosophy of SUID. Thus, it can also extend the understanding of the role of users in the system. To summarize quickly: a SELinux system is designed to allow for a much more flexible way, which is also more accurate and much better suited to your needs, to identify and help implement user roles within the system.
Summary
This is really only a quick introduction to SELinux. The article describes the basics of the mechanism used on a daily basis in this system. It still does not do anything special, but the desire to write a summary of what it is captivated me. On our website, with SELinux we often capture 50 fixes critical to the security system in a very short time, less than seven days. Another decisive advantage is its ease of use. As a Linux system administrator, I have never met a tool that uses such simple rules, yet describes so much. Yet very few administrators so far know the SELinux system.
No comments:
Post a Comment