What is Chroot

Chroot is the change root, which is the location of the root directory that is referenced when the program executes. General Directory Schema:
/
/bin
/sbin
/usr/bin
/home

Directory schema for Chroot:
/hell/
/hell/bin
/hell/usr/bin
/hell/home
* Why do we have to chroot?

1. Limit the programs that can be executed by the chroot user, such as the SETUID program, or the compiler that will cause the load.
2. Prevent users from accessing certain files, such as/etc/passwd.
3. Prevent intruders from/BIN/RM-RF/.
4. Provide guest service and punish the bad user.
5. Improve the security of the system.

* How to create a chroot environment?
1.chroot () This function:
The chroot (PATH) function must have the identity of root to execute, and the directory will be switched to the location specified by path after execution.
The process of 2.login:
Users must perform/usr/bin/login to determine whether they can enter the system, whether from console or Telnet, and the actions of login are:
(1) The sign of login is printed out, waiting for the user to enter the password.
(2) Check the password is correct, the wrong word back (1).
(3) The correct words to setuid () to change the identity of Login_user.
(4) Execute user's shell with exec ().

Therefore, we must first modify the/usr/bin/login source code, let login in (2) to (3) in the middle of the execution of CHROOT ($CHROOT _path) action, has achieved CHROOT purposes, and with modified login to replace the original/ Usr/bin/login.
(5) A slightly better method must check the login user's group before doing chroot (), and if a particular group (such as CHROOTGRP) executes chroot (), all the people will be chroot.

3. The environment required for the establishment of Chroot:
(1) Required directory: (assuming $chroot is the path you want to build)
$CHROOT/etc $CHROOT/lib $CHROOT/bin
$CHROOT/sbin $CHROOT/usr/lib $CHROOT/usr/bin
$CHROOT/usr/bin $CHROOT/usr/local $CHROOT/home
(2) Careful examination of the files in the/etc, need to have the implementation of the program required files, such as passwd,groups,hosts,resolv.conf and so on.
(3) Take away the executable files that you don't want to give, such as Su,sudo setuid programs, and compiler even telnet.
(4) test, as root execution chroot $CHROOT/bin/sh can enter the chroot environment. (Mans chroot for details)
4. Try the console or Telnet entry.
5.username/password Resolve's considerations:
In chroot you may not want the chroot user (Chrooter) to get/etc/passwd or/etc/shadow files, especially with the root password. Here are three scenarios:
(1)/etc/passwd is the same as $CHROOT/etc/passwd: This is the worst practice, because one is chrooter to get the encrypted password of root, secondly, to keep/etc/passwd and $chroot/ The synchronization of ETC/PASSWD is a big problem. Because/usr/bin/login reference is/etc/passwd, but once Chrooter is CHROOT to execute passwd, the passwd he executes will change $chroot/etc/passwd.
(2)/etc/passwd differs from $CHROOT/ETC/PASSWD:
You can take away the passwords of important characters in the $chroot/etc/passwd, such as root, and then modify them in a more complex way.
/usr/bin/login:
if (Has_chroot_group) {
Re-load $CHROOT/etc/passwd
if (password is valid) {
Chroot ($CHROOT)
EXEC (Shell)
else Logout ()
}
The advantage of this method is that you can separate/etc/passwd from $CHROOT/ETC/PASSWD. /ETC/PASSWD only affects the username that Chrooter uses in login, others such as
Password even uid,gid,shell,home and so on are reference $chroot/etc/passwd.
The disadvantage is that your other daemon, such as FTPD,HTTPD, must make the same changes to get the Chrooter information right, and you must change/etc/passwd and $chroot/etc/when you add or remove a user from the Chroot_group. passwd

(3) Using NIS/YP:
This method is probably the simplest and the least troublesome. Because all the user information through NIS bind to obtain, not only can protect the password of the root, also save/etc/passwd with
$CHROOT/etc/passwd The problem of synchronization management. Not only passwd, but also other such as groups,hosts,services,aliases and so on can be solved together.

* Other issues to be considered:
1. Synchronization of the execution file:
To update the system or update the software, you must take into account the replacement of the $chroot directory files, especially, such as SunOS or BSD will use Nlist () to obtain kernel information, in the update kernel must be updated $chroot under kernel.
2./dev's Problem:
In general, you have to mount/dev Read-write to $chroot/dev with local loopback NFS to allow common user and chrooter to write to each other and solve devices synchronization problems.
3./proc's Problem:
On Linux or SysV or 4.4BSD systems, many programs will refer to/proc data, and you must also mount/proc to $chroot/proc.
4./var's Problem:
In general/var also use the local loopback NFS Read-write mount to $chroot/var to solve the spool synchronization problem, otherwise you may have to modify the LPD or sendmail, etc. daemon, otherwise they do not know There are spool in the $CHROOT/var.
5.Daemon problem:
You must modify some of the user-related daemon such as ftpd,httpd so that these daemon can find the correct user home.

* Chroot security issues that cannot be resolved:
1. Accidentally or forget to take off the SETUID program:
Chrooter still have the opportunity to use Setuid program to get root permission, but because you have been CHROOT him, so can affect only the $chroot/directory below the file, even if he came to a "/BIN/RM-RF/" is not afraid.
But what other root can do is not prevent, such as using tcpdump to eavesdrop on the communication in the LocalNet and obtain the account password of other machines on the localnet, reboot machine, change NIS data, Change the password of other accounts that are not chroot to obtain a general account number (so root is not included in NIS) and so on.
(At this point, you must prevent it from being login as root by Securetty or login.access or by taking the wheel group out of NIS)
2. Daemon that have been loaded into memory:
For those who boot on the program such as SENDMAIL,HTTPD,GOPHERD,INETD, and so on, if these daemon have hole (such as SendMail), then hacker as long as the cracking of these daemon can still get root permissions.

Conclusion
Chroot can improve the security of the system and limit what the user can do, but chroot is not Everything, because there are other vulnerabilities waiting for hacker to find out.