jail breaking

这一部分为转载，转自jail-breaking

Till now you have been struggling for getting the root user on the system via different techniques. What if I told you are already a root user but still can’t access some files and don’t even have /root directory or other directories like /sys or /proc

Well, don’t get deceived by such root environments. These types of environments are called chroot jails. Today I will put some light on breaking out of chrooting jail environment using the second-chroot method

What is chroot anyway?

Have you ever encountered a situation where the system is powered off while updating the kernel version and when you switch on again, the kernel panic happens? To fix this what actually you do is

1. Boot live Linux OS
2. Mount the root partition
3. Chroot to the new partition and fix the issue
4. Reboot the system and remove Live OS USB

Chroot is a syscall and command-line utility that changes the root directory for the current running process and its children to create file system level isolation, don’t confuse it with the current working directory.

The top of file hierarchy in Linux OS is root (/), you can not go above beyond this. So even if you perform cd .. on the root directory, it will land you in the same directory only. For instance, here I performed *cd ..* 100 times on root directory

Enough talk, let’s see chroot in action

Here, I am creating the chroot directory, copying files necessary for the chroot environment to spawn a shell and continue execution.

# id -ur ; whoami 
0
root
# mkdir chroot
# cp -a bin/ usr/ lib/ root/ chroot/
# ls 
bin     chroot  dev     etc     home    lib     media  ... truncated
# chroot chroot/ sh
# id -ur ; whoami 
0
whoami: unknown uid 0
# ls 
bin   lib   root  usr

Did you notice, whoami command failed with a message “unknown uid 0“, this is because the utility command is looking for /etc/passwd file to compare uid = 0 with the name of the user. I did not intentionally copy that directory to show that there is no way for a regular program to break out of the chroot environment and read the real file system.

However, the environment variables are passed from the host to the chrooted environment.

# export NAME=tbhaxor
# chroot chroot/ 
# echo $NAME
tbhaxor

All the commands will inherit the root directory from chroot and environment variables from the host. If you add or modify any environment variables here, it will not affect the host shell

If you are looking for the real-world use cases of the chroot environment, they are already listed here on its Wikipedia page – https://en.wikipedia.org/wiki/Chroot#Uses

Understanding Process CWD vs ROOT

Linux /proc filesystem manages two paths for the currently running process.

• cwd – current working directory of the process
• root – root directory of the process

A root directory is a symlink to the Linux file system where actually the program is running. Usually, it is set to / but for the chrooted environment it is set to the path of the directory passed as the first argument to chroot command. It can not be changed by process directly, but chroot() syscall does this.

The current working directory is the symlink to the directory where the process is currently running from its root directory. This can be easily changed by calling cd shell utility or chdir() syscall.

Allow me to show this in a chrooted environment practically. To demonstrate I will keep the **cat** process open on the chrooted environment will look at the /proc file system from the host file system.

# ps -eaf
PID   USER     TIME  COMMAND
    1 root      0:00 /bin/sh
   14 root      0:00 bash
   22 root      0:00 bash
   58 root      0:00 /bin/sh -i
   60 root      0:00 cat
   62 root      0:00 ps -eaf
# ls -l /proc/60/cwd
lrwxrwxrwx    1 root     root             0 Aug 22 22:12 /proc/60/cwd -> /chroot
# ls -l /proc/60/root
lrwxrwxrwx    1 root     root             0 Aug 22 22:12 /proc/60/root -> /chroot

Now after changing the directory to “/usr/bin“ in the chrooted environment and again run the cat program.

As you can see, cwd is changed but is appended to the root directory. Apparently, in the host file system, it will start from /, not any other folder like **/chroot** in this case.