What is chroot? JDLI@csie.nctu.edu.tw (2001-04-16 13:51:59) * What is Chroot?
Chroot is Change Root, which is the root directory location referenced when the program is changed.
General catalog architecture: / / bin / sbin / usr / bin / home
Chroot catalog architecture: / Hell / / Hell / bin / Hell / USR / BIN / HELL / HOME
* Why do you want chroot?
1. Limit the programs that Chroot can perform, such as SETUID's program, or cause LOAD's Compiler, etc. 2. Prevent users from accessing certain specific files, such as / etc / passwd. 3. Prevent intruder / bin / rm-rf /. 4. Provide guest services and users who are punished. 5. Enhance the security of the system.
* How do I create a chroot environment? 1.chroot () This function: chroot (path) This function must have root's identity to execute, and will switch to the directory to PATH after execution. 2.Login process: Users must perform / usr / bin / login to decide whether to enter the system, both from console or telnet, and the movement of Login is roughly: (1) Printing the prompt of the Login Symbol, wait for the user to enter the password. (2) Check if the password is correct, if the error is returned (1). (3) The correct words change the identity to login_user in SetUID (). (4) Execute the shell of the USER with exec (). Therefore, we must first modify the Source Code of / USR / BIN / LOGIN to make Login execute chroot ($ chroot_path) in the middle of (2) to (3), and have reached the purpose of Chroot, and replaced by modified login is originally / Usr / bin / login. (5) Slightly a little better method must check the group of Login User before doing Chroot (), if there is a particular group (such as ChrootGRP) to execute Chroot (), otherwise all people will be chroot.
3. Establishing the environment required for Chroot: (1) Directors that must be available: (Suppose $ chroot is the path to Hope created) $ chroot / etc $ chroot / lib $ chroot / bin $ chroot / sbin $ chroot / usr / lib $ chroot / usr / lib $ Chroot / USR / BIN $ Chroot / USR / BIN $ Chroot / USR / Local $ Chroot / Home (2) Carefully review files in ETC, need to have the files required to execute, such as Passwd, Groups, Hosts, Resolv .conf, etc. (3) Take off the executive files that do not want to give, such as SU, SUDO, etc. SETUID, and Compiler even telnet. (4) Test, perform chroot $ chroot / bin / sh as root to enter the Chroot environment. (Man Chroot for Details)
4. Try it in Console or Telnet.
5. Excise ofUsername / Password Resolve: You may not want to be able to get / etc / passwd or / etc / shadow such as Chroot, especially if there is a root password. There are three scenarios: (1) / etc / passwd is the same as $ chroot / etc / passwd: this is the worst method, because it has a chance to get root by chrooter to get root's Encrypted Password, two to keep / etc / passwd and The synchronization of $ chroot / etc / passwd is a big problem. Because / usr / bin / login reference is / etc / passwd, once Chrooter executes passwd after Chroot, the Passwd he performs will be $ chroot / etc / passwd. (2) / etc / passwd Different $ chroot / etc / passwd: You can take off the important characters in $ chroot / etc / passwd (such as root), then modify / usr / bin / us with complicated methods Login: if (HAS_CHROOT_GROUP) {RE-load $ chroot / etc / passwdiff {chroot ($ chroot) Exec (shell)} Else logout ()} The benefit of this method is that you can / etc / passwd Separate with $ chroot / etc / passwd. / etc / passwd only affects the username used by Chrooter during Login, others such as Password or even UID, GID, Shell, HOME, etc. are all reference $ chroot / etc / passwd. Disadvantages is that your other Daemon is as FTPD, and HTTPD must do the same modification to properly take the Chrooter information, and you must change / etc / passwd with $ chroot / etc / passwd when adding a user to or remove Chroot_Group. (3) Using NIS / YP: This method is probably the easiest and the least trouble. Because everything goes through Nis Bind, it can not only protect the root password, but also the issue of / etc / passwd with $ chroot / etc / passwd synchronous management. Not just Passwd, even other groups, hosts, services, aliases, etc. can be resolved.
* Other questions must be considered: 1. Synchronization of the execution file: When you update your system or update your software, you must consider the files under the $ chroot directory, especially if Sunos or BSD will use nlist (). Get kernel information, you must update the kernel under $ chroot when you update Kernel. 2./DEV Problem: In general, you must use local loopback NFS to make / dev read- Write Mount to $ Chroot / dev so that general user can mutual WRITE and solve DEVICES synchronization issues. 3./Proc problem: In Linux or Sysv or 4.4BSD system, many programs will go to the reference / proc information, you must also / Proc Mount to $ Chroot / Proc. 4./VAR problem: Generally, the Word / VAR is also under the Local Loopback NFS Read-Write Mount to $ Chroot / VAR to resolve the SPD synchronization problem, otherwise you may have to modify the LPD or Sendmail, etc. They don't know that there is a spool existence under $ chroot / var. 5.Daemon Question: You must modify some of the Daemon related to users such as ftpd, httpd so that these Daemon can find the correct User Home. * Chroot Unable to resolve security issues: 1. Don't carefully or forget to take off the setuid: Chrooter still has the opportunity to use the setuid program to get root permissions, but because you have already chroot, what you can affect Only the files below the chroot / directory, even if he is "/ bin / rm -rf /" is not afraid. However, other root can do something or not, if using TCPDUMP to hit communication in the localnet and get the account password, Reboot machine, change NIS information on the localnet, change the password without the CHROOT Borrow to obtain a general account (so root cannot be added to NIS), etc.. (At this point, you must take the NIS by SecureTty or Login.Access or to prevent it from Login as root. 2. DAEMON in the memory: The programs such as Sendmail are executed for those boots. Httpd, gopherd, inetd, etc. If these Daemon has Hole (such as Sendmail), the Hacker can get these Daemon or get root privileges.
* Conclusion: Chroot can enhance system security, limit users, but chroot is not everything, because there is still other vulnerabilities waiting for Hacker to find.
-------------------------------------------------- ----------------------------- by jdli@csie.nctu.edu.tw
