Secure Programming: minimize privileges to eradicate software defects

Article title: Secure Programming: minimizing privileges to eradicate software defects. Linux is a technology channel of the IT lab in China. Includes basic categories such as desktop applications, Linux system management, kernel research, embedded systems, and open source.
Secure programs must minimize privileges to reduce the possibility of converting bugs into security defects. This article discusses how to minimize privileges by minimizing privileged modules, granted privileges, and the effective time of privileges. This article not only discusses some traditional UNIX-like privileged mechanisms, but also discusses newer mechanisms, such as FreeBSD's jail () and Linux Security Module (Linux Security Modules, LSM) frameworks, and Security-Enhanced Linux (SELinux ).
　　
On June 18, March 3, 2003, Internet Security Systems issued a warning about a serious vulnerability in Sendmail. All emails are transmitted through the mail transfer agent (MTA), while Sendmail is the most popular MTA. Therefore, this warning affects many organizations around the world. The problem is that, according to the general configuration, the "from", "to", or "cc" domain email messages are carefully set to make the sender completely (root) controls any machine running Sendmail. More seriously, a firewall cannot protect its internal machines from such attacks.
　　
The direct cause of this vulnerability is that a security detection of Sendmail is defective and a buffer overflow may occur. However, an important factor is that Sendmail is often installed as a single "setuid root" program with full control permissions on the system running it. In this way, any defects in Sendmail allow attackers to directly control the entire system.
　　
Is this design necessary? No; the Postfix of Wietse Venema is a common MTA that can rival it. Similar to Sendmail, Postfix performs many security checks. however, to minimize the privilege, Postfix is designed as a set of modules. As a result, Postfix is generally considered to be a safer program than Sendmail. This article discusses how to minimize privileges and apply the same idea to your program.
　　
　　 Minimal privilege basis
The actual application may have defects. It's not what we want, but it does. Complex requirements, schedules, and environment changes make it unlikely to produce practical, defect-free programs. Even those programs that officially prove to be correct through complex and accurate technologies also have defects. Why? One of the reasons is that verification requires many assumptions, and these assumptions are generally not completely correct. In any case, for various reasons, most procedures are not strictly tested. Moreover, even if there are no defects today (unlikely), future maintenance changes or environmental changes may introduce defects. Therefore, to deal with actual problems, we have to develop secure programs in some way, despite the defects in our programs.
　　
Despite these flaws, the most important way to secure programming is to minimize privileges. The privilege is only allowed to do things that not everyone can do. In UNIX-like systems, "root" users, other users, or members of a group are the most common types of privileges. Some systems allow you to grant privileges to read or write specific files. However, in any case, minimize the privileges:
　　
Grant privileges only to the part of the program that requires privileges
Grant only some specific privileges that are absolutely required
Limit the privileged validity period or valid time to the absolute minimum
These are actually goals, not absolute. Your basic organization (such as your operating system or virtual machine) may make it difficult to strictly complete these tasks, or it may be complicated to strictly complete these tasks, as a result, more defects are introduced when the attempt is strictly completed. However, the closer you are to these goals, the lower the possibility of security problems caused by defects. Even if a defect causes a security problem, the severity of the security problem may be lower. Moreover, if you can ensure that only a small number of programs have specific privileges, you can use a large amount of extra time to ensure that part can withstand attacks. This idea is not new; Saltzer and Schroeder's excellent 1975 papers discuss the security principle and explicitly treat the minimal privilege as a principle (see references ). There are some ideas that are permanent, such as minimizing privileges.
　　
The next three sections will discuss these goals in sequence, including how to implement them in UNIX-like systems. Next, we will discuss some of the special mechanisms available in FreeBSD and Linux, including the Security-Enhanced Linux (SELinux) discussion of NSA.
　　
　　 Minimize privileged modules
As mentioned above, only some programs that require special permissions have special permissions. That is to say, when you design your program, try to break it into independent parts so that only small and independent parts require specific privileges.
　　
If different parts must run simultaneously, use a process (not a thread) in UNIX-like systems ). Threads share their security privileges. problematic threads may interfere with all other threads in the process. When writing a privileged part, it will be attacked as another program: a day may be! Make sure that the privileged part only does as few things as possible; restricted functions mean that they are not easy to use.
　　
A common method is to create command-line tools with extremely limited functions with specific privileges (such as setuid or setgid. The UNIX passwd command is an example. it is a command line tool with special privileges, used to change the password (setuid root), but all it can do is change the password. Therefore, various GUI tools can require passwd for actual changes. If possible, try to avoid creating the setuid or setgid program completely, because it is difficult to ensure that you are truly protecting all input. However, sometimes you need to create the setuid/setgid program, so when necessary, try to minimize and limit the program.
　　
There are many other methods. For example, you can have a small "server" process with specific privileges; that server allows only specific requests, and only after confirming that the requester is allowed to send a request. Another common method is to start a program with the privilege, which then derives the second process that gives up all the privileges, and this process does most of the work.
　　
Be careful how these modules communicate with each other. In many UNIX-like systems, the command line value and environment can be seen by other users, so it is not a good way to send data securely between processes. Pipelines are competent, but be careful to avoid deadlocks (a simple request/response protocol that can be refreshed at both ends can be competent ).
　　
　　 Minimize granted privileges
Make sure that you only grant privileges to the programs you actually need-so far. The main way for UNIX to gain privileges is to run them as the user or group. Generally, processes run as users and groups that use them. However, programs with "setuid" or "setgid" receive privileges from users or groups that own this program.
　　
Sadly, there are still some developers on UNIX-like systems that give the program the "setuid root" privilege. These developers think they make things "easy" for themselves, because they don't have to worry about what privileges their program needs. The problem is that since these programs can do almost everything on most UNIX-like systems, any defect can quickly become a security disaster.
　　
Do not give all possible privileges simply because you need to complete a simple task. Instead, only the privileges required by the program should be granted. If you can, run them with setgid instead of using setuid -- setgid to grant less privileges. Create specific users and groups (do not use root) and use them as needed. Make sure that the executable programs owned by root can only be written by root, so that others cannot modify them. Set very strict file permissions-if not absolutely required, do not allow everyone to read or write files and use specific users and groups. One example of all of these may be the standard practice of the game's "top ten" score. Many programs are "setgid games", so that only game programs can modify the "top ten" score, the files that store these scores are owned by the games group (and only this group can be written ). Even if an attacker attacks and enters a game program, all he can do is to modify the score file. In any case, game developers still need to write their programs to prevent malicious score files.
　　
Chroot () system calling is a practical tool-unfortunately there are some difficulties. When a process views the "root" of the file system, the system call modifies the content seen by the process. If you plan to use it -- and it may be practical -- be prepared to take some time to make good use of it. "New root" must be carefully prepared, which is complex because the exact application depends on the features of the platform and application. You must use the root identity for the chroot () call, and you should quickly change the non-root identity (the root user can leave the chroot environment, so if it takes effect, you need to revoke that privilege ). In addition, chroot does not change network access. This can be a practical system call, and sometimes it needs to be considered, but it should be well prepared.
　　
Resource restriction is a tool that is often forgotten. This includes both stored resources and process resources. These restrictions are particularly useful for DoS attacks:
　　
For storage, you can set a quota for the storage capacity or number of files of each mounted file system for each user or group ). Check quota (1), quotactl (2), and quotaon (8) in the GNU/Linux system to learn more about this function. However, although they are not available anywhere, most UNIX-like systems include the quota system. In GNU/Linux and many other systems, you can set hard and soft boundaries (which can be temporarily exceeded ).
　　
For processes, you can set many limits, such as the number of opened files, number of processes, and so on. This capability is actually part of the standard (such as a Single UNIX Specification), which is almost ubiquitous in UNIX-like systems. For more information, see getrlimit (2) setrlimit (2), getrusage (2), sysconf (3), and ulimit (1 ). Processes can never exceed the "current limit", but they can raise the current limit all the way to the "upper limit ". Unfortunately, an unreasonable term may confuse you. The "current boundary" is also called a "soft" boundary, and the upper limit is also called a "hard" boundary. In this way, you will be in an unusual situation where the process can never exceed the soft (current) boundary of the process -- and for quota, you can exceed the soft boundary. I recommend that you use the terms "current boundary" and "upper limit" for process boundaries (never use the terms "soft" and "hard"), so that there is no confusion.
　　
　　 Time to minimize privileges
Only grant privileges when necessary-do not give them more in a moment.
　　
Whenever possible, use whatever privileges you need immediately, and then permanently discard them. Once they are permanently abandoned, subsequent attackers cannot exploit those privileges in other ways. For example, programs that require individual root privileges may be started as root (for example, by becoming setuid root) and then switched to run as less privileged users. This is the method used by many Internet servers (including Apache Web servers. UNIX-like systems do not allow any program to open 0 to 102