[Forever UNIX> what is chroot? ]

* What is chroot?

Chroot is the change root, that is, the root category location of the test taken when the program is modified.

General architecture:
/
/Bin
/Sbin
/Usr/bin
/Home

The architecture of the chroot project is as follows:
/Hell/
/Hell/bin
/Hell/usr/bin
/Hell/home

* Why chroot?

1. Restrict programs that can be opened by the chroot user, such as the setuid program, or cause
Load compiler and so on.
2. Prevent users from accessing some specific issue cases, such as/etc/passwd.
3. prevent intruders/bin/Rm-RF /.
4. Provide the guest service and users with poor handling capabilities.
5. enhance the security of the system.

* How do I establish a chroot environment?
1. chroot () This function:
The chroot (PATH) function must have the root identity before the row can be merged.
Switch the cursor to the place specified by path.
2. login process:
Whether the user enters from the console or telnet, the user must upload/usr/bin/login.
Determine whether the system can be imported. The actions login performs are as follows:
(1) print the login prompt and wait for the user to encrypt it.
(2) check whether the password is correct. If the password is correct, return to (1 ).
(3) Use setuid () to change the identity to login_user.
(4) execute exec () into the shell of the user.
Therefore, we must first modify the source code of/usr/bin/login so that login ranges from (2) to (3)
The chroot ($ chroot_path) action has been completed to the chroot purpose, and
The modified login replaces the original/usr/bin/login.
(5) a slightly better method must be checked by logging login before chroot ().
User Group, if there is a specific group (such as chrootgrp)
The chroot () command is executed before the chroot () command is executed. Otherwise, all users will be killed by the chroot command.

3. create the environment required by chroot:
(1) the destination must have been: (false $ chroot is the path to be created)
$ Chroot/etc $ chroot/Lib $ chroot/bin
$ Chroot/sbin $ chroot/usr/lib $ chroot/usr/bin
$ Chroot/usr/bin $ chroot/usr/local $ chroot/home
(2) When checking the case in/etc, it is necessary to have the sequence required during the rolling schedule.
Such as passwd, groups, hosts, and resolv. conf.
(3) Remove the program that does not want to give the token, such as the setuid program such as Su and sudo,
And compiler or even Telnet.
(4) Submit the chroot $ chroot/bin/sh line as the root user.
You can enter the chroot environment. (Man chroot for details)

4. Enter zookeeper in the console or via Telnet.

5. Considerations for username/password resolve:
You may not want the chroot user
Chrooter) can get the/etc/passwd or/etc/shadow
Case, especially with root password. There are three scenarios:
(1)/etc/passwd is the same as $ chroot/etc/passwd:
This is the worst practice, because a chrooter has the chance to get the root
The encrypted password of, and the/etc/passwd and
$ Chroot/etc/passwd synchronization is a big problem. Because
/Usr/bin/login tests/etc/passwd, but once
When the row passwd is written after the chrooter is chroot
Passwd will change to $ chroot/etc/passwd.
(2)/etc/passwd is different from $ chroot/etc/passwd:
You can set important characters in $ chroot/etc/passwd (such as root)
The password is removed, and then modified in a way that is more complex than others.
/Usr/bin/login:
If (has_chroot_group ){
Re-load $ chroot/etc/passwd
If (password is valid ){
Chroot ($ chroot)
Exec (Shell)
} Else logout ()
}
The good thing about this method is that you can connect/etc/passwd
$ Chroot/etc/passwd separated. /Etc/passwd only shadow
The username used by chrooter in login.
Password, even uid, GID, Shell, home, and so on
$ Chroot/etc/passwd.
Other daemon such as ftpd and httpd must be the same.
To obtain the correct chrooter information.
Individual users must be modified when they are added to or removed from chroot_group.
/Etc/passwd and $ chroot/etc/passwd.

(3) Use NIS/yp:
This method is probably the most simple and the least troublesome. Because all users
Information is obtained through NIS bind, which not only can be saved
Root Password, saving/etc/passwd and
$ Chroot/etc/passwd synchronization management issues. Not just
Passwd, others such as groups, hosts, services,
Aliases and so on.

* Other required questions:
1. Synchronization of merge rows:
When updating the system or updating the internal system, you must take a test to update the system.
For example, SunOS or BSD
NLIST () to obtain the kernel information.
The kernel under $ chroot must be updated.
2./dev problems:
Generally, you must use local loopback NFS to forward/dev read-
Write mount to $ chroot/dev to make the average user and chrooter
Write Data to each other and solve the synchronization problem of devices.
3./proc problems:
Many programs in Linux, sysv, or 4.4bsd
Test/proc information, you must also mount/proc
$ Chroot/proc.
4./var:
In general,/var also uses local loopback NFS read-write
Mount to $ chroot/var to solve the spool synchronization problem,
Otherwise, you may have to modify the daemon such as lpd or Sendmail,
Otherwise, they do not know that spool exists under $ chroot/var.
5. Daemon problems:
You must modify some daemon related to users, such as ftpd and httpd.
So that these daemon can find the correct user home.

* Security issues cannot be solved by chroot:
1. accidentally or forget to remove the setuid program:
Chrooter still has the chance to use the setuid program to get the root
Permission control, but because you have already chroot him
Only the lower case of $ chroot/, even if
"/Bin/Rm-RF/" is not afraid.
However, other root actions cannot be prevented, such as using tcpdump.
Listen to the tunnel in the localnet and obtain the other
Token secret of the machine, reboot machine, change the NIS information, change
Other passwords without chroot authentication are used to obtain the general signature (
Cannot be added to NIS as root.
(At this time, you must use securetty, login. access, or
Wheel group uses NIs to prevent its Login as root)
2. You have logged on to the daemon:
For those programs that just run on the machine, such as Sendmail and httpd,
Gopherd, inetd, etc. If these Daemon have hole (such
Sendmail), then the hacker can still obtain
Root permission.

* Conclusion:
Chroot can enhance the security of the system and limit what users can do,
But chroot is not everything, because there are other
Vulnerabilities are identified by hacker.

This article is transferred from
Http://fanqiang.chinaunix.net/a1/b5/20010416/134954.html