Safety procedures must minimize privileges, to reduce the bug into the possibility of security flaws. This article discusses how to minimize the privileged modules, the privileges and the privileges granted to the effective time to minimize privileges.
Article not only discusses some of the traditional UNIX privileged class of mechanisms, also discussed the relatively new mechanisms, such as FreeBSD's jail (), Linux Security Module (Linux Security Modules, LSM) framework, and the Security-Enhanced Linux (SELinux).
March 3, 2003, Internet Security Systems on Sendmail in a serious vulnerability warned. All e-mail through the message transfer agent (mail transfer agent, MTA) to transfer, Sendmail is the most popular MTA, so this warning affected many organizations worldwide. The problem is, according to the usual configuration, carefully set the "from", "to" or "cc" field of email messages allows the sender complete (root) control of any one machine running Sendmail. More seriously, the general firewall will not protect against such attacks inside the machine.
The direct cause of this loophole because, Sendmail has a security flaw detection, buffer overflow can occur. However, an important role in factor, Sendmail is often installed as a single "setuid root" program, run it on the system has full control permissions. This, Sendmail flaw in any of those who can allow an attacker direct control of the entire system.
This design is necessary? No; Wietse Venema's Postfix is a common can match it's MTA. Like Sendmail, Postfix will do a lot of safety testing, however, in order to minimize privileges, Postfix designed as a set of modules. The results, Postfix is generally considered more secure than Sendmail program. This article discusses how to minimize privileges, you can apply the same thinking to your program.
Minimize the basis of privilege
Practical application of the procedures have shortcomings. Do we really want it, but really it is. Complex needs, schedule pressures and changes in the environment is unlikely to be practical so flawless process. Even those who have passed complex and sophisticated technology to formally prove the correct procedure, there will be flaws. Why? One of the reasons is that verification must be done a number of assumptions, and often these assumptions are not entirely correct. In any case, for various reasons, most of the procedures had not been a rigorous test. Moreover, even today there is no defect (unlikely), the future maintenance of the change or changes in the environment are likely to introduce defects. Therefore, to deal with practical issues, we have some way to develop security procedures, despite the defects in our program.
Despite these shortcomings, the security program is the most important way is to minimize the privilege. Privilege do not just allow everyone can do. UNIX systems in the class, with "root" user, other users or members of a group of privileges is the most common types of privileges. Some systems allow you to grant read or write privileges to specific files. But anyway, to minimize privileges:
Only part of the program need the privileges granted the privileges
Only part of it is absolutely necessary to grant specific privileges
The privileges of the effective time or can be effectively restricted to the absolute minimum time
The fact is the goal, not absolute. The basis of your organization (such as your operating system or virtual machine) may make strict completion of these is not easy, or the strict completion of these may be very complicated, which led to the completion of trying to introduce more stringent defect. However, the closer you from those goals, the possibility of defects lead to lower security. Even if the defect had security problems, which led to the security problem could be even lower. And if you can ensure that only a small part of the program has specific privileges, you can use a lot of extra time to ensure that part that can withstand attacks. This idea is not new; Saltzer and Schroeder's excellent 1975 paper discussed the principles of safety, explicitly as a principle of minimum privilege (see Resources). Some ideas are timeless, such as minimizing the privilege.
The next three sections will discuss these objectives in turn, including how to achieve their class UNIX systems. Then, we will discuss the FreeBSD and Linux in some special mechanisms available, including the NSA's Security-Enhanced Linux (SELinux) discussion.
Minimize privileged modules
As mentioned earlier, only to be privileged part of the program only applied privileged. This means that when you design your program, try to process broken down into separate parts, to make only a small portion of the independent needs of specific privileges.
If different parts must be run, then use the UNIX-system processes (not threads). Threads share their security privileges, the thread in question may interfere with the process of all the other threads. Privileged part of the preparation, on the other programs as it is being attacked: one day will be! Ensure that privileged part of the only things to do as little as possible; limited functionality means less likely to be used.
A common approach is to create an extremely limited function has specific privileges (such as a setuid or setgid) command-line tool. UNIX's passwd command is an example; it is a particular privilege command-line tools for modifying the password (setuid root), but it can do is change your password. So can request a variety of GUI tools to do the actual change passwd. If possible, try to completely avoid creating setuid or setgid program, it is difficult to ensure that you are truly protect all input. However, sometimes you need to create a setuid / setgid programs, so when necessary, as far as possible to process the smallest and most limited.
There are many other ways. For example, you can have a special privilege of a small "server (server)" process; that the server allows only specific request, but only confirmed that the requester is allowed to issue the request. Another common approach is to start using the privileges of a program, the program then derived to give up all the privileges of the second process, the process by doing most of the work.
Be careful how these modules communicate with each other. In many UNIX-systems, command-line value and the environment can be seen by other users, so it is not in the process of sending data between the secret to a good way. Pipeline can be competent, but to carefully avoid the deadlock (two ends can refresh a simple request / response protocol can be competent).
Minimize privileges granted
To ensure that you only need to grant privileges to do the procedure - stop here. UNIX main way to obtain privileges to which they run as a user or group. Typically, the process to use their running as users and groups, but, "setuid" or "setgid" program will be have the program user or group privileges.
Sadly, there are some involuntary way to program "setuid root" privileges on UNIX-systems developers. The developers think they make things for themselves to become "easy" because they do not go in-depth account of their procedures is a definite need any special privileges. The problem is, since most of these programs to be made class UNIX systems do almost everything, so any defects can quickly become a security disaster.
Not just because you need to complete a simple task to give all possible privileges. The procedure should only be given the privileges they need. If you can, to setgid to run them, not to use setuid - setgid privileges less. Create a specific user and group (do not use root), and use them according to your needs. To ensure that those owned by root executable only by root to write, so that others can not modify them. File permissions set very strict - if not absolutely necessary, do not let everyone can read or write files, and use those specific users and groups. Can explain all of these games may be an example of "top ten" scores of standard practice. Many procedures are "setgid games", to make only the game program can be modified "top ten" scores, and scores of documents stored in the master group are games (and only this group can write). Even if the attacker attack and entered a game program, all he could do would be modify the scores of documents. In any case, game developers still need to write their programs to prevent malicious score file.
chroot () system call is a useful tool - unfortunately there are some difficult to use. When the process view the file system "root", this system call will modify the process to see the content. If you plan to use it - and it may be useful - to be ready to take some time to make good use of it. Must be carefully prepared "new root", which is complicated because the exact application depends on the platform and application characteristics. You must be root, to be chroot () call, and you should quickly change the status of non-root (root users from the chroot environment, so if it is to take effect, you need to lift the privilege). And chroot will not change network access. This can be a useful system calls, all sometimes need to consider it, but the effort to do well prepared.
Limited resources is an often forgotten tool, which includes both the process of storage resources, including resources. These restrictions denial of service attacks are particularly useful:
Storage for, you can set for each user or group for each mounted file system or file number storage quota (limit). In GNU / Linux system, see quota (1), quotactl (2) and quotaon (8) to in-depth understanding of this feature, however, where even though they are not able to use most of the class of UNIX systems include the quota system. In GNU / Linux and many other systems, you can set "hard" limits (never exceed) and "soft" limits (which can be temporary excess).
The process is, you can set many limits, such as the number of open files, the number of processes, and so on. This capability is actually part of the standard (such as a single UNIX Specification (Single UNIX Specification)), all of them in the class UNIX systems almost ubiquitous; to understand, see getrlimit (2), setrlimit (2) and getrusage ( 2), sysconf (3) and ulimit (1). Process can never exceed the "current line", but they can limit all the way to rise to the current "cap." Unfortunately, there is a anomaly term problems may make you confuse. "Current line" is also known as "soft" boundaries, limit, also known as "hard" boundaries. This way, you will be in an unusual situation, the process can never exceed the limits of the process of soft (current) limits - and you can exceed the soft quota limit is. I propose to limit the process of using the term "current line" and "cap" (never use the term "soft" and "hard"), so there would be no confused.
Minimize the time privilege
But only when required to provide privileges - do not give a moment.
Whenever possible, use no matter what your immediate need, privileges, and then give them up permanently. Once they have been permanently abandoned, then the attacker can not otherwise make use of those privileges. For example, the need for individual root privileges to root, the procedure may start (for example, through a setuid root) and then switch to the less privileged user to run. This is the number of Internet servers (including the Apache Web server) the methods used. Class UNIX systems do not allow any program to open 0 到 1024 TCP / IP port; you must have root privileges. But most servers only need to open ports boot time, after the privilege was no longer need. One way is to run as root, as soon as possible to open privileged ports needed, and then permanently remove the root privileges (including the process belongs to any privileged group). Going to try to remove all other inherited privileges; for example, shut down as soon as possible need specific privileges to open the file.
If you can not permanently give up privileges, then you can at least temporary removal of privileges as often as possible. This is better than permanently removing the privileges, because if an attacker can control your program, the attacker can re-enable the privilege and use it. Nevertheless, it is worth doing.
Many attacks only when they have the privilege of deceiving the procedure to do some things outside the program and the program's privileges are enabled to succeed (for example, by creating a symbolic link anomaly and hard links). If the program usually does not enable its privileges, then the attacker would like to take advantage of this program will be more difficult.
Relatively new mechanism
So far, we discussed the principles actually apply to almost all operating systems, and, since the 19th century, since the 70's, almost all UNIX-系统 of conventional mechanisms are similar to. That does not mean that they are useless; simple and the test of time is their own advantage. However, some relatively new class of UNIX systems has increased to support least privilege mechanism, it is worth to know. Although it is easy to find time-tested mechanism, but on the relatively new mechanism for information not yet known. So, here I will discuss some valuable mechanism selected: FreeBSD jail (), Linux Security Module (LSM) framework and the Security-Enhanced Linux (SELinux).
FreeBSD jail ()
chroot () system call has a lot of problems, as mentioned above. For example, it is difficult to correct use, root user can still learn from, but it does not control network access. FreeBSD developers decided to add a new system call to solve these problems, the new system call called jail (). This call is similar to chroot (), but try to use easier and more efficient to use. In a jail, all the requests (even root's) are limited jail, and jail in the process can only communicate with other processes, and the system blocked the root user attempts to jail the way from the typical. jail will be assigned a specific IP address, can not use any other address as its own address.
jail () call is unique to FreeBSD, which limits its usefulness. However, all OSS / FS has a lot of crossover between the impact of the kernel (cross-pollination). For example, using the Linux security framework has been developed for the Linux version of a jail. Moreover, FreeBSD 5 has added a flexible MAC frame (from TrustedBSD project), including the basic functions of a module similar to SELinux. All, in the future to see more of this situation do not be surprised.
Linux Security Module (LSM)
In the 2001 Linux Kernel Summit on, Linus Torvalds has a problem. A number of different security projects, including the Security-Enhanced Linux (SELinux) project, asking him to add their security methods to Linux kernel. The problem is that these different methods are often incompatible. Torvalds is no simple way to determine which one is best, so he asked those projects together to create a common Linux security framework. So, the administrator can give them any special installation method they want security. After several discussions with Torvalds, Crispin Cowan set up a group to create the common security framework. This framework is named Linux Security Module (LSM) framework, it is now part of the standard Linux kernel (such as the 2.6 version of the kernel).
Conceptually, LSM framework is particularly simple. Linux kernel is still doing its routine safety inspection; example, if you write a file, you still need to have write access to its.
However, whenever necessary if the Linux kernel should allow access to determine whether it should be checked - by a "book" to demand a security module to carry out - to determine whether the permit action. In this way, administrators can simply select that he wants to use the security module, and the same as other Linux kernel module insert. Since then, the security module will determine what is permitted.
LSM framework designed to be so flexible that it can achieve many different types of security policies. In fact, a number of different projects together to ensure that sufficient competent LSM framework of the real work. For example, when the internal object is created or deleted when the LSM into a number of calls - is not because those operations may be suspended, but to the security module can keep track of important data. Using a number of different analytical tools to ensure that the LSM framework does not miss any important abnormalities of their target branch. The results show that the project than many people think harder, and its success is hard won.
LSM is necessary to understand the basic design decisions made. Basically, LSM framework was designed for almost all branches are limited exceptions, not reliable (authoritative). Branch to make a credible abnormal absolute final decision: If the exception is the branch that a request should be allowed, it will be unconditionally allowed. On the contrary, can only increase the credibility of the abnormal branch of the other restrictions; it can not grant new rights. Theoretically, if all branches are credible abnormal LSM, LSM framework will be more flexible. One called capable () exception branch is trusted - but only because it had to support the POSIX regular capacity. However, the letter can make all the abnormal branches, it is necessary to the Linux kernel, many fundamental changes, says the change is not allowed to be accepted.
Many people fear that if most of the hook can be believed, even the smallest defect will become a disaster; and let the hook Shouxian means that users will not be surprised (In any case, the original UNIX permissions still work) . LSM framework so developers who wish to limit the method, and most of its developers confident they can work within the framework.
LSM framework for understanding other restrictions is also important. LSM framework is designed to support access control, auditing and other security issues are not. LSM module itself does not record all requests or their results, because they can not see all. Why? One reason is that the kernel may not call the LSM module refused the request; If you would like to audit this refusal will be a problem. Also, due to performance reasons, some of the proposed branch for network anomalies and LSM data field is not used by the kernel thread. It can control a number of network access, but not enough to support the "labelled" network data stream (in this case, different data packets have different security labels handled by the operating system). These restrictions are inappropriate, inconsistent with the basic principles of general ideas; LSM framework has been extended one day hope to get rid of these restrictions.
Nevertheless, even with these restrictions, LSM framework to limit the privileges to add it is still very useful. Torvalds LSM framework by the fundamental objective is realized: "I do not like the struggle between different security groups. I hope that is indirect, let me out of this struggle, then the market may struggle to decide which strategy and applied to achieve the ultimate . "
So, if you want to restrict Linux granted the privilege of your program, you can create entirely your own security module. If you use a real external constraints that may need to do so - fortunately this is possible. However, this is very important; anyway, you still have to write kernel code. If possible, you best not to use the existing Linux security module, but try to write your own security module. Some available LSM module, but, Security-Enhanced Linux (SELinux) is the most mature one Linux security module, so let us examine this module.
Security-Enhanced Linux (SELinux) history
A little history will help to help you understand the Security-Enhanced Linux (SELinux) - and it itself is a fun history. U.S. National Security Agency (National Security Agency, NSA) long has been concerned with the security of most operating systems, limited capacity. After all, one of them is to ensure that the U.S. Department of Defense to use the computer in the face of endless attacks to maintain security. NSA found that most of the operating system's security mechanisms, including Windows and most UNIX and Linux systems, only achieved a "selective access control (discretionary access control)" (DAC) mechanism. DAC system is to run the program under the user's identity and documents to determine the owner of the object program can do. NSA think this is a serious problem, because the DAC itself vulnerable or malicious program is a failure of protection are. Instead, NSA has long been hoped that the operating system can also support "mandatory access control (mandatory access control)" (MAC) mechanism.
MAC mechanism allows the system administrator can define security policies throughout the system, this strategy can be based on other factors, such as the user's role, the program's credibility and the expected use, the program will use the type of data, etc., to limit the program can What to do things. A small example, with the MAC after the user can not easily "secret (Secret)" data into "non-confidential (Unclassified)" data. However, MAC can actually do much more than that.
NSA has been with the operating system providers for many years, but many of the largest market share provider of integration for the MAC is not interested in coming. Even the providers that integrates MAC is usually also be used as "separate products", rather than conventional products. Partly because the old MAC is not flexible enough.
So try to NSA's research efforts and make more flexible MAC and easily be included in the operating system. They use the Mach operating system developed prototypes of their ideas, and later expanded the work initiated by "Fluke" of the operating system.
However, it is difficult to convince people that these ideas can be applied to "real" operating system, because all these are based on tiny "toy-class" research project. Very few outside the prototype can try to see these ideas in a real application of how to work. NSA can not convince a provider of title to add these ideas, and NSA had no right to modify the proprietary operating system. This is not a new problem; years ago, DARPA tried to force its proprietary operating system, researchers used the operating system Windows, but encountered many problems (see references below).
So, NSA came across a thought in retrospect seems obvious: to use a toy is not open-source operating system, and implement their security ideas to show that (1) it can work, (2) it is specific to the work (through for all source code). They chose the dominant market, open source kernel (Linux) and in which the realization of their idea that "security-enhanced Linux" (SELinux). Not surprisingly, use the real system (Linux) for NSA researchers can deal with them in the toy can not deal with. For example, in most Linux-based systems, almost all are dynamically linked, so they had to do something about the program how to perform in-depth analysis (access to them on the "entrypoint" and "execute" permission documentation for more information). This is a much more successful way; people who are using SELinux prototype earlier than those who use a lot more.
SELinux to work
So, SELinux to work for? SELinux method actually very common. An important core of each object, such as each file system object, and each process has a correlation to their "security context (security context)". Security context could be based on military security level (if not confidential, confidential and highly confidential), based on user roles, application-based (so, a Web server can have its own security context), or on many other elements. When it executes another program, the process can change the security context. Even, depending on the procedure call it, a given program can run in different security contexts, even if a user starts with all the procedures.
Then the system administrator can specify which privileges granted to create a security context with which the "security policy (security policy)". When the system call occurs when, SELinux to check whether all the required privileges have been granted - and if not, it refused the request.
For example, to create a file, the security context of the current process to the parent directory's security context on the "Search (search)" and "add_name" privilege, and it needs to (to create) files in the security context of the "Create ( create) "privilege. Similarly, the security context of that file with the file system must have the privilege of "related (associated)" (So, for example, "highly confidential" documents can not write a "no confidence" in the disk). Also for sockets, network interfaces, host and port of the network access control. If the security policy for those who are all granted permissions, then the request will be allowed by SELinux. Otherwise, they will be banned. If you do it step by step all of these checks will be slower, but there are many optimization program (based on years of research) to make it very quickly.
The examination was independent of the class system in the usual UNIX permissions bits; in the SELinux system, you must type both the standard UNIX permissions, there SELinux permission to do something. However, SELinux checks can do a lot of the traditional UNIX permissions for the class is difficult to achieve.
Using SELinux, you can easily create a specific program can only run and only in the context of a particular Web server to write files. Even more interesting is that if an attacker scored a Web server and become root, the attacker will not be given control of the entire system - if there is a good security policy, then.
It has been difficult: In order for SELinux effectively, you need to have a good reason behind SELinux security policy implementation. Most users will need a practical easy to modify their initial strategy. A few years ago I began to experience the SELinux; that time, the initial strategy is not yet ripe, there are many problems. For example, in those days before I found the early sample policy does not allow the system update the hardware clock (the last I submitted a patch to address this issue). Good initial security policy design similar to the product category, NSA hopes to do by the business community, and look to do so. Red Hat, a number of Debian developers, Gentoo and others are using the basic SELinux framework, and the initial security policy is being created, so that users can immediately start using it. Indeed, Red Hat plans to all users in their operation in both Fedora Core SELinux, and provide simple tools to enable non-professional user can select some of the common options to modify their security policy. There is a bootable Gentoo SELinux LiveCD. Minimize these groups will make it easier to process privilege, without a lot of code.
Here we are back to the original position. SELinux only occur when the program execution only to allow the secure transmission, which controls the process of competence (not a part of the process). Therefore, to fully exploit the potential of SELinux, you need to decompose your application process and procedures for independent, only some small privileged components - just like how this situation developed in the absence of SELinux security procedures. Tools such as SELinux allows you to better control the permissions granted, and so create a stronger defense, but you still need to split your program into smaller components to enable those who control the play maximum effectiveness.
Conclusion
Minimize the security issues privilege is the most important defense. As the defect is unavoidable, you will want to greatly reduce the possibility of defects lead to security problems. However, at least one security program must be related to the safety of some parts of the code, so you can not only minimizes the expense of all other privileges. Even when you have to minimize some of those involved in security after the part or those who must be correct. To the right, you need to avoid common mistakes.