[Z] The Demon (daemon) process that imprisoned you

Matt Borland translator: nixe0n

Brief introduction
A summary of the concept of chroot cage (jail)
Postfix Wizard Process Analysis
A imprison (jail) howto:icecast

First step: Install Icecast in a cage (jail) environment
Step Two: Configure the cage (jail) environment
Step three: Create a chroot package for this Genie

Where you can't use the prison environment
Conclusion

Brief introduction

We often hear about computers being attacked by Internet-based remote attacks. Usually at the forefront of the attack are some server software, such as Web, mail, and DNS, which are usually provided through the monitoring process (daemon, also known as the daemon process). These services, even after a firewall, face a variety of probes and attacks that allow attackers to gain access to the system. Most malicious attackers install rootkits on the system so that they can perform the usual system operations.

In general, these rootkits and viruses need to use the target system's executable files, dynamic connection libraries, and configuration files. For example, a rootkit installed on a Linux host may need to access/bin/sh or be able to read and write system configuration files in the/etc directory. And once the system is hacked by the attacker, the attacker gets root privileges and can run to modify any files he or she needs. The recent lion, ramen worm attack on bind can prove the point.

But what if you restrict the daemon process (daemon) to access only the necessary files and not the entire file system? This will make our security no longer dependent on the security level of the Daemon software developer.

Fortunately, Unix systems can provide such a mechanism to implement this idea. In a recent bind attack, Thaumaturgix, Inc. 's IT administrator, William Cox, proposed "running a server process in a chrooted environment to reduce your exposure" (the best way to limit your exposure is T o Run the server in a chrooted environment)). This chrooted environment is often called a chroot cage (jail), which in fact has been around for a long time, but has not been fully exploited by software developers and system administrators.

A summary of the concept of chroot cage (jail)

Implementing a chroot jail consists of two ways:

1. Restrict a process to access only a subset of the entire file system.

2. Run the service process with lower privileges.

Both of these approaches are provided by some standard system tuning. First, it is chroot (), a system call that restricts the process's access to the file system. Even if a process is running as root, its access to files/directories is also a subdirectory of the entire file system relative to the chroot () system call limit.

For example, if a process executes a chroot () system call with/var/sample/jail as a parameter, it now accesses a file:/etc/passwd, but the operating system eventually replaces the access request with a pair of/var/sample/jail/etc/ PASSWD's access. Chroot system calls can only be called with root permissions.

System calls that reduce process permissions include: Setuid (), Setgid (), and setgroups (). Setuid () specifies the actual and valid user rights for the process, while Setgid () specifies the actual and valid group permissions for the process. The setuid () system is very important, and once it enters a lower privilege, the process will not be able to regain root privileges on its own. Setgroups () defines the Append group membership for the process. In addition, there are other related system calls that users can obtain from their own system's hand albums.

Other types of operating systems may have additional process-binding methods. For example, there is a jail () function in FreeBSD. To give you a better sense of the benefits of jailing, I'll illustrate with a typical rootkit that, under different permissions and without being confined to the jail environment, rootkits harm the system differently. Here, always remember one thing, when a service is compromised, an attacker can have the privileges of the service process. Take a look at the following table:

+-----------------+---------------------------------------\
| | | |
| | Running as root | Running Non-root |
| | | |
+-----------------+-------------------+-------------------|
| | | |
| Entire FS | (a) | (c) |
| | | |
|-----------------+-------------------+-------------------|
| | | |
| Jailed FS | (b) | (d) |
| | | |
+---------------------------------------------------------/

Processes running in the (a) class (processes running with root privileges and having access to the entire file system) are the preferred target for rootkits, and intrusion into such services can allow an attacker to modify a binary executable such as/bin/ps,/bin/netstat, and so on, to open a privileged network port, Read any system file including:/etc/shadow file. Worst of all, they are able to completely destroy the system, for example: RM-RF/. One of the most common examples of running in this state is sendmail.

If the service process is in the (B) class (Root, Cage) state, generic rootkits may not work properly because they typically require a shell (/bin/sh) and some basic commands, such as/BIN/RM and/BIN/CP. However, in this state, the rootkit can still break the cage (jail). Because the service process runs with root privileges, an attacker can directly perform some operations that allow root execution by attacking the code (for example, directly referencing an index node of a file system outside the cage). Therefore, this state is more secure than the (a) class (higher threshold), but it does not provide sufficient protection for the service.

The service process is in the (c) class (non-root and can access the entire file system) and the threat to the whole system is smaller than the (a) state because the attacker cannot gain root privileges directly. However, if the service process is in this state, once an attacker invades the service, it is possible to execute commands to get a shell to interact with, and then be likely to gain root privileges through a local attack. Even if the attacker does not have root privileges, they can access most of the system's configuration files and other information, such as the user's e-mail account information (a large number of spam messages will flock).

Finally, service processes in the (d) class (non-root, jail environment) are the most restrictive, so that the attacker has no chance to execute the shell at all, and it is impossible to obtain a large amount of system information. Furthermore, all damage to the system is restricted to the jail environment. In this state, the biggest threat is an attacker placing an executable file that can be accessed by a process outside the jail environment in this jail environment, thus spreading the attack code out of the jail environment. Therefore, you should always monitor your cage and see if the prisoner has escaped: P.

Below we will give a realistic example to illustrate.

Postfix Wizard Process Analysis

Postfix is a mail transfer agent (mail Transfer agent). It allows users to receive/send SMTP messages and deliver messages to local users to the user host. Postfix is a sendmail, the author Wietse Venema to the security issue has poured a lot of attention. This software is a very typical so-called disciplined Elf (disciplined Daemon), which can be installed in a chroot cage (jail) environment. I believe that understanding how postfix works, you can implement a simple security Genie (daemon).

Postfix starts with a program called Master, and master starts with root, and then continues to run with root privileges. However, master itself is very small and its role is the spawn process, which is mostly placed in a chroot cage (jail) environment to perform the actual work. In this way, the number of code running with root privileges is very limited.

Let's take a look at how master interacts with SMTPD. Master once it detects a connection to port 25th (the SMTP listening port), it executes the smtpd. Let's take a look at some of the jailing methods used by Postfix, which are in the Src/util/chroot_uid.c file. During the narration, we use/var/spool/postfix as the root directory of the chroot Cage (jail) environment:

+-----------------------------+-----------------+--------------------\
| | User/group | FileSystem |
+-----------------------------+-----------------+--------------------|
| Master is run on startup | Root/root | / |
|-----------------------------+-----------------+--------------------|
| Master Opens port 25 | Root/root | / |
|-----------------------------+-----------------+--------------------|
| Master Detects connection | Root/root | / |
|-----------------------------+-----------------+--------------------|
| Master Forks smtpd | Root/root | / |
|-----------------------------+-----------------+--------------------|
| Master Continues execution | Root/root | / |
|-----------------------------+-----------------+--------------------|
| SMTPD Inherits Permissions | Root/root | / |
|-----------------------------+-----------------+--------------------|
| SMPTD calls Setgid () | Root/postfix | / |
|-----------------------------+-----------------+--------------------|
| SMPTD calls Initgroups () * | Root/postfix | / |
|-----------------------------+-----------------+--------------------|
| SMTPD calls Chroot () | Root/postfix | /var/spool/postfix |
|-----------------------------+-----------------+--------------------|
| SMPTD calls setuid () | Postfix/postfix | /var/spool/postfix |
|-----------------------------+-----------------+--------------------|
| SMTPD Processes Connection | Postfix/postfix | /var/spool/postfix |
|-----------------------------+-----------------+--------------------|
| SMTPD Continues listening | Postfix/postfix | /var/spool/postfix |
+-----------------------------+-----------------+--------------------/
* Initgroups () similar to setgroups (); Set up a multi-reorganization member relationship.

Finally, the status of the SMTPD process is as follows (503 is the ID of the Postfix user/group):

#cat/proc/<pid>status

Name:smtpd
State:s (sleeping)
pid:1301
ppid:665
tracerpid:0
UID:503 503 503 503
GID:503 503 503 503
fdsize:256
groups:503
[...]

After the connection is processed, the SMTPD Wizard continues to listen for the SMTP connection and, if there is no connection within the specified time, exits.

From the above procedure you can have a general understanding of the evolution of the process state. Throughout the life cycle, SMTPD starts with a (a) state, then enters (b), and then quickly enters the (d) state and finally runs in the (d) state. In fact, this is the standard step in putting the process into the correct chroot Cage (jail) environment .

A jail Howto:icecast

Understanding these background knowledge is useful, but how to imprison a daemon process? Furthermore, is it still up to the daemon itself to imprison an elf process? To answer these questions, I will tell you about an actual daemon, though it is relatively simple, but the author does not give a wizard to imprison the document. However, please note: Some popular elf systems such as BIND, already have a document on how to create a chroot cage environment.

In our case, the program I chose is called Icecast. Icecast is an audio streaming relay server that obtains audio streams from a network-based client program (for example, Winamp) and then receives a number of listeners ' connections to allow listeners to listen to a continuous stream of audio. I want to run this program on my own machine, but I'm afraid there is a security flaw in the service, so I want to limit it.

Let's take a look at the start of this service, 3 This daemon opens two ports that do not require root access, one for receiving audio streams, and the other for connecting to the client program. It can also be maintained through a local console during the run, but this is not required. In addition, Icecast also maintains a log file during operation.

This program runs with non-root privileges, which is good. However, if it is not imprisoned (jail), in theory if it is hacked by an attacker, allowing the attacker to acquire a shell, the attacker could spy on my system and even gain root privileges through other local attacks. So I'm going to imprison Icecast (jail).

Here are our confinement processes:

Install the wizard to the specified directory and assign it the smallest possible file access when it is guaranteed to function properly. Remove all unnecessary items from this cage (jail) directory.

Make the necessary configuration for this cage environment. This environment typically includes: Dynamic connection library files run by sprites, a local/dev/null device, and some local time information may also be required.

If necessary, create a function wrapper (wrapper) that performs chroot and discards the teach-in privilege. If the genie can think of the postfix as a child, you don't have to do it yourself. Note: Be sure to place these packages (wrapper) outside the cage (jail) environment.

First step: Install Icecast in a cage (jail) environment

First, we install all icecast files into the/usr/local/icecast directory, in our case,/usr/local/icecast is the root of the Icecast Cage (jail). Where you install the cage (jail) environment is very important and probably should be a read-only file system.

The following is the contents of its installation directory, the owner of the Icecast installation directory is root

Drwxr-xr-x 2 root root 4096 May 6 14:38 bin
Drwxr-xr-x 2 root root 4096 may 18:43 conf
Drwxr-xr-x 2 root root 4096 May 6 14:38 doc
Drwxr-xr-x 2 root root 4096 May 6 14:41 logs
Drwxr-xr-x 2 root root 4096 may 16:41 static
Drwxr-xr-x 2 root root 4096 May 6 14:38 templates

Reading Icecast's documentation and some experiments, we know that icecast normal operation requires the following file/directory permissions:

Executable: Bin/icecast
Writable: Logs Directory
Readable: conf, static, and templates directories

Now, I decided to build a user named Icecast and use this user to run Icecast. In executing this service, I need to write the log to the logs directory, and I don't want anyone to be able to write this directory, so I build this new user.

#useradd icecast-s/bin/false

Then, you should find the following entry in/etc/passwd, and the account is locked and cannot be logged in:

Icecast:x:505:505::/usr/local/icecast:/bin/false

Now, we need to decide what documents are needed and where they should be placed. First, we need to change the permissions of the logs subdirectory, and we can delete the unnecessary subdirectory doc.

Icecast, unlike Postfix's subprocess, is able to invoke chroot system calls on its own, so in order to execute wrapper after executing the chroot wrapper (icecast) program, we need to put the Bin/icecast executable in this cage ( Jail) environment. Then we need to write a chroot wrapper that puts him outside the prison (jail) environment.

In addition, Icecast also needs to be in the Conf directory configuration file. We assume that Icecast is already installed in the/usr/local/icecast directory.

Step Two: Configure the cage (jail) environment

The goal of this step is to identify the dynamic connection libraries that the icecast needs to run and install them into the cage (jail) environment, which may vary by system. Without these dynamic connection libraries, Icecast will not be able to execute, and this causes the execution error message to be confusing, such as:/bin/icecast:file not found

In a Linux system, you can run the LDD program to see the dynamic connection libraries required by Icecast and their location on the file system. For example (all commands are executed in the/usr/local/icecast directory):

$ LDD Bin/icecast
libm.so.6 =/lib/i686/libm.so.6 (0x40022000)
libpthread.so.0 =/lib/i686/libpthread.so.0 (0x40046000)
libc.so.6 =/lib/i686/libc.so.6 (0x4005b000)
/lib/ld-linux.so.2 =/lib/ld-linux.so.2 (0x40000000)

Now, we copy these dynamic connection libraries to a similar location in this cage (jail):

# mkdir-p lib/i686
# cp-pi/lib/i686/libm.so.6/lib/i686/libpthread.so.0/lib/i686/libc.so.6 lib/i686
# cp-pi/lib/ld-linux.so.2 Lib

In this way, these dynamic connection libraries are copied to the/lib directory of the Cage (jail), which means that bin/icecast can be executed in a cage.

However, this is not enough, in any cage environment to build a/dev/null device is a very good idea:

# mkdir Dev
# mknod-m 666 dev/null C 1 3

Be cautious about this step and be sure that you have set up the device node correctly.

Many services may require a system/etc/localtime file. Finally, we need to copy the/etc/localtime file to the/usr/local/icecast/etc/directory and add a symbolic connection to the/usr/local/icecast/usr/lib/zoneinfo:

# mkdir etc
# mkdir Usr/lib
# Cp/etc/localtime etc
# ln-s/etc/localtime Usr/lib/zoneinfo

Now, the cells we have prepared for the Icecast elves have been renovated almost, with the following directories:

Drwxr-xr-x 2 root root 4096 May 6 14:38 bin
Drwxr-xr-x 2 root root 4096 may 18:43 conf
Drwxr-xr-x 2 root root 4096 may 18:01 Dev
Drwxr-xr-x 2 root root 4096 May 6 14:38 doc
Drwxr-xr-x 2 root root 4096 may 14:41 etc
Drwxr-xr-x 2 root root 4096 May 15:30 Lib
Drwxr-xr-x 2 Icecast icecast 4096 May 6 14:41 logs
Drwxr-xr-x 2 root root 4096 may 16:41 static
Drwxr-xr-x 2 root root 4096 May 6 14:38 templates
Drwxr-xr-x 3 root root 4096 may 14:42 usr

Step three: Create a chroot package for this Genie

Remember that executing chroot requires root access.

You might think that I would be able to put the Icecast genie into a prison environment by first executing the/usr/sbin/chroot and then executing the/BIN/SU and then executing the/bin/icecast. But don't forget, once the/usr/sbin/chroot is executed, you can no longer access the entire file system, which means you will not be able to execute the SU program. It is also possible to put Su in this cage, but its associated files are very complex and difficult to maintain, and Su is a suid program that is placed in this environment and will certainly reduce the security of the environment.

It is a relatively easy solution to write a short C program that invokes the necessary jail system calls and then executes the Icecast service. This program will be executed outside of this cage, and it needs to do the following things:

Execute the chroot system call and enter the cage.
Set the group identifier and group membership to Icecast.
Set the user identifier to Icecast.
Execute/bin/icecast.

One thing to note: The permissions of this program cannot be set to the Setuid/setgid bit. Our goal is to call Setuid ()/setgid () system calls with Superuser privileges to lower the system's permissions, and to set the program's permissions to Suid or Sgid to a great difference. Putting the Suid/sgid of a program to a program that runs with the permissions of the owner usually means that the program is running with more privileges.

Below I provide a simplified chroot wrapper. Note: In practice, you should pay attention to the error handling of each system call.

=================================================
#include
#include

Main (argc, argv) {

int gidlist[] = {505};

Chroot ("/usr/local/icecast");
ChDir ("/");

Setgid (505);
Setgroups (1,gidlist); Also, could use initgroups

Setuid (505);

Execl ("/bin/icecast", "/bin/icecast", null);

}
==================================================

Also note here, do not put this program in the background to execute. In this example, I just need to modify the Icecast configuration file to enable Icecast to run in the background.

Now our cage has been done, as long as the implementation of the above packaging procedures, you can put icecast imprisoned in the inside: P. The above packaging program you can put in any of your favorite location, just do not put in the/usr/local/icecast directory on it. You can also include this wrapper in the Autostart script so that Icecast can run automatically when the system starts.

Where you can't use the prison environment

In some cases, it is unlikely that the management of the daemon will be implemented.

Let's look at the Apache Web server. Apache developers are very aware of their security issues when developing this software, and the httpd process is typically started with root privileges, and the processes that derive from it are processed under relatively low permissions (usually nobody), just like the relationship between master/smtpd. That is, the httpd process that handles customer requests runs in the Class C state.

Although you can also imprison Apache Web servers, in some cases this work is almost impossible to accomplish. For example: In the Web server, you use the PHP module, PHP module is very rich in features, its dynamic connection library is very complex, in this case, create a cage environment is not worth the candle.

Another situation is that if the daemon does require access to the file system, for example, some components of postfix do require root permission to post messages to the user's directory.

Conclusion

I find that few people are paying attention to the realization of a chroot cage environment, hoping that this article will give you a good idea of the benefits of imprisoning the daemon and help you to achieve your own prison environment.

Reference:

(1) Fearnow, Matt. "Lion worm." Sans Global Incident Analysis Center, April 2001.
Http://www.sans.org/y2k/lion.htm

(2) Radcliff, Deborah. "Stuck in a Bind" Computerworld, February 2001.
http://www.itworld.com/net/4055/cwsto57547

(3) FreeBSD, Inc. "Jail () man page" April 1999.
Http://www.freebsd.org/cgi/man.cgi?query=jail&sektion=2&apropos=0&manpath=freebsd+4.0-release

(4) Burr, Simon. "How to break out of a chroot () jail." January 2001.
Http://www.bpfh.net/simes/computing/chroot-break.html

(5) Wunsch, Scott "Chroot-bind howto" Linux Documentation Project, September 2000.
Http://www.linuxdoc.org/howto/chroot-bind-howto.html

(6) Deatrich, Denice. "How to chroot a Apache tree with Linux and Solaris." February 2001.
Http://penguin.epfl.ch/chroot.html

Moen, Rick "Attacking Linux" linuxworld.com, August 29 2000.
http://www.itworld.com/sec/2199/lwd000829hacking/

Fennelly, Carole "real hackers go to Usenix" Unix Insider, November 17 2000
http://www.itworld.com/sec/2052/uir001117security/

Brumley, David. "Invisible intruders:rootkits in Practice" Usenix, November 1999.
Http://www.usenix.org/publications/login/1999-9/features/rootkits.html

Miller, Toby. "Analysis of the T0rn rootkit" Giac, 2000. Http://www.sans.org/y2k/t0rn.htm

[Z] The Demon (daemon) process that imprisoned you