xch­root

Introduction

Chroot allows you to run commands from a different system installation without having to boot into that system. You do not even need a separate partition for the alternate system installation or root file system. This does of course only work if both systems are Linux installations or both systems are BSD derivates since they will always need a compatible kernel to be in operation. Just shared libraries (*.so, Windows: dll) are loaded from the new root on program invocation out of the chroot environment. Newer kernels use to be backward compatible. Thus chrooting into an elder system installation would always be possible. There are a few exceptions like the old ddrescue program using a deprecated kernel api which is no more supported. Backward compatibility of kernels is also the reason why statically linked programs use to continue to run even without preserving a full chroot environment for them.

Chroot is particularely useful if you have installed more than one Linux distro and want to run programs from another distro than you have actually booted to. Chroot is also widely in use for program development and packaging as it can simulate another environment very well allowing to test on multiple systems at the same time. It can also be used to run programs that are no more available for recent Linux distros.

Chroot works immediately and guarantees minimal effort. You do not have to wait until another system is booted. Memory usage is as little as possible. Under Linux it is possible for a cracker to escape from a chroot environment while chroot-jails are also considered a security feature in FreeBSD.

The only thing you basically have to do in order to change to another chroot environment (i.e. another installed system) is to issue a chroot command as root on the directory that should become the new root of the file system. Use exit to get back to your boot-root.

problems with a pure chroot

Nonetheless you may find out soon that this does not work for many many programs; f.i. you are not able to run any GUI applications as you can not connect to a running X server inside a chroot environment without special provisions even under Linux which allows programs to 'escape' from chroot environments.

For further instructions on how to secure a chroot environment under Linux that does not need X access you may want to have a look at Grsecurity (though booting the system in a virtual machine is the best option for means of security.). Be aware that allowing compromized programs to connect to the same X server (the program that is responsible for graphics output under unixoid systems) together with uncompromized programs will compromize the rest of your system at least as long as no MAC (Mandatory Access System) like SELinux is in place that is able to controlle your X server and adherent programs like DBUS; be it a 'secured' chroot environment or not. We suggest that even with SELinux exploits can likely be used as the X-server is a hard target for confinement. That can be as simple as pasting text into a root console and letting it disappear by appropriate escape sequences fractions of milliseconds thereafter! A more sophisticated attacker will exploit vulnerabilities of your X server. It is an ideal target for exploits as the X server is feature rich and running as root!

There are even more restrictions: you can not run programs such as grub that need access to either /dev, /sys or your /proc filesystem as long as these systems are not mounted properly (i.e. recursively) into the new chroot environment. If you have installed a fresh system and want to access your old installation via xchroot you may want to verify your old installation with a tool like debcheckroot first in order not to infect your new system.

trying to resolve these problems by hand

As far as now you may already know that a pure chroot is very restricted. f.i. You can not run any GUI-applications. A workaround for this is to redirect all Xorg drawing operations through localhost: > xhost +localhost > DISPLAY=localhost:0 chroot /dst/debian;

However this does not work if your X server (being responsible for all graphical output) has been startet with the -nolisten tcp option which is the default now for reasons of security even if you don´t specify that option. You may start an additional X-server with xinit twm -- :1 vt08 -listen tcp for testing purposes. As your primary X-server is usually started automatically by your display manager you would need to configure your display manager to allow tcp access for exploiting this option. Here is a section you can add to your /etc/lightdm/lightdm.conf if you are using lightdm rather than xdm, sddm, kdm or gdm as your display manager:

Find out about the command line X has been started with by the following command:

You can watch your tcp conncetions on the loopback interface with tcpdump -i lo or wireshark -i lo -k. Note that tcp access is quite a serious security risk if you do not block the respective ports starting from 6000 by your firewall (see netstat -atupn as root). Moreover funneling all traffic via tcp is slow and your X-clients will not be able to make use of shared memory access.

Access to/via localhost is a reason why you may want to allow X access via socket files in your chroot. You will need to mount your socket file /tmp/.X11-unix/X0 to /dst/debian/tmp/.X11-unix/X0. Note that mount --bind does not only work for mount points but also for any other directory like /tmp/.X11-unix or even for files like /proc/cmdline (helpful if you are stuck in your initrd). A proper socat on that file also does the job. Pure symbolic links do not work since a link equals to the character string of the referenced file which points to something different after the chroot. Finally you need a xhost +local: to allow all local clients to connect.

Note that allowing all local clients to connect either via xhost +localhost or xhost +local: is also quite a grave security risk. It means that any user can connect to the X-server. If a daemon or service executes code as some user on your machine that code will have it easy to become root via your X-server (see last section). You can not run sshd on such a machine except if any user that connects via ssh should have unrestricted root rights on your machine. Nonetheless there is also a solution to this problem.

X servers can and usually do use an additional authentication mechanism based on cookies. Keep in mind that cookies are transmitted unencrypted to the X server so that they could be eavesdropped by anyone if transmitted via the local network. Thus you may want to establish an ssh or vpn tunnel whenever you connect to a remote X server in order not to allow any other user access to the same X server who listens on the same net (use ssh -X). Nonetheless this authentication mechanism can be used securely for different users on the same machine and whenever you do only interconnect two machines mutually by a non-eavesdroppable point to point connection.

Now in practice the file that stores the cookie for authentication with the X-server defaults either to ~/.Xauthority or whenever the $XAUTHORITY variable is set then it holds the path and file name of the Xauthority file. The access rights of these files need to be chosen in a way so that other users can not read or write to them. You may simply copy these files though the correct way for adding entries to these files goes via an xauth extract and xauth merge. If you have more than one X-server or sshd running you will likely want to give your chroot only access to your current X-display, not all of them. Copying the file will delete the file in your target chroot which may result in things to stop working there. Consider an sshd in your chroot and a client who connected to it with ssh -X there.

Furthermore we already discuessed programs like grub or gparted that need direct access to your disk devices at /dev. You may simply mirror your /dev to /dst/my-distro/dev in this example before you issue a chroot which can be accomplished by mount --bind /dev /dst/my-distro/dev. Proceed the same way for your /sys and /proc directory which are required by many programs as an additional interface to expose and set kernel data. Note that also subdirectories may require their own mounts as /dev/pts/* for terminals.

All of that is why we want to encourage you to use xchroot instead of tinkering with half brewn solutions as you can find them eleswhere on the web. It will save you from breaking little things and finally it will also save you from quite severe security risks.

xchroot and users: the background

If you have xchroot forget all the other *chroot-s! You do not even need that to chroot as user. If everything is set up correctly run xchroot as user and root alike. Use addsudoers, delsudoers and listsudoers to configure your user setup. More examples can be found in the man page.

Internally the -u/--user option and sudo implement this: A simple

will do what you want provided that you execute it as root.
A simple entry in your /etc/sudoers leverages the use directly as user usr:

letting you open any root under /dst as user usr. (instead of 'ALL' a host name may be stated in case that the /etc/sudoers is distributed to many hosts but should not be allowed on all of them.) You will have to be extremely careful when adding sudoer entries on your own. /etc/sudoers does not use regular expressions but shell pattern globbing which means that an asterisk "*" can stand for any combination of characters including spaces. It thus does usually only make sense to use one star per line at the end in sudoers.

Now we do also want to pass optional parameters to xchroot. Unfortunately we can not put these parameters in front of our root filesystem /dst/* (which stands for 'distribution') because otherwise we could also wildcard our root filesystem specification which is likely not what we want. By this reason the developers of xchroot have invented a little trick: put the -t option in front and put any other option after a '--' at the end right after your root and program specification. The --user option is not allowed in the tail. We will show you by the following example how it works:

Note that we have used the unsecure -E option which is disallowed by /etc/sudoers which passes all the environment variables along to the new chroot environment. In a fact the only environment variables we need to keep in order for xchroot to function are $DISPLAY, $XAUTHORITY and $XCHROOT_MYROOT. Now let us drop the -E option and merely pass along the variables we need:

elm:~> sudo xchroot -u elm /dst/debchroot/ --env DISPLAY=:0 --env XAUTHORITY=$XAUTHORITY --env XCHROOT_MYROOT=$XCHROOT_MYROOT

That`s it.

Oops?! Haven`t we forgotten about -- before the trailing options and the -t in front? These options are not required as long as you do only use --env as tail option and optionally --noask as the very last option. --noask keeps programs running in the chroot on exit without asking the user whether he/she wants to terminate them. Note that the --user option can not be used as tail option because that would compromize our security needs.

Rather complicated?
I just wanted to show you how xchroot as user works internally so that you can understand why and what it puts into /etc/sudoers.

xchroot and users: user administration commands, tail options

Let us see another example of addsudoers first:

The first addsudoers allows the user elm to xchroot to any directory below /dst/. Note the trailing slash: It is necessary in order not to allow xchrooting to any directory name that starts with /dst. Then we allow the user shell to issue a user-xchroot upon /dst/debchroot and only upon this directory. Host user will be elm. The user in the chroot is shell. This means you need to specify -u shell as you invoke as elm. Finally we list all sudoer entries: addsudoers adds four sudoer entries for every access record: Allowing to invoke xchroot with and without tail opts ([-]t) and finally allowing to issue cleanups for whenever you have invoked xchroot with --noask, killed it or chosen to leave some programs running. Use delsudoers to delete a given group of sudoer entries. You may furthermore remove the lines with [-]t manually to disable tail option parsing for the given user.

Now what is tail option parsing? Tail option parsing allows you to put options at the end rather than letting the options precede your chroot directory and the command to execute in the new chroot. Tail options work like the following: Put the [-]t option in front and all other options at the end after an "--". This has become necessary because of the wildcarding feature of sudoers: A wildcard can stand for any combination of letters. That is why we may only wildcard after specifying user and root filesystem. Have a look at the following examples:

The first one does not need any option besides -u, the second one needs -t in front because we have -- --aufs at the back. Note that you may add any number of options after the --. Finally I wanna show on how to remove a user spec where 'all' stands for any user with the delsudoers command:

Now to keep things clear and to see which chroot environment you are currently working in a goodie for colorful user prompts designed especially for use with xchroot (put it in your .bashrc);

Xorg/X11 access as root

Now it may be the case that you have Xorg access by issuing an xchroot but not after a su or sudo su whenever you wanna become root for some purpose. Your distro should normally automatically complete this task by an adequate bash startup. However you can also establish this yourself; a topic which is not directly related to xchroot but which may be very useful in the context of xchroot. The bash environment variable XAUTHORITY points to a file which is by default called ~/.Xauthority and which contains a cookie the client needs to obtain access from the Xorg/X11 server. To move the cookie from /home/usr/.Xauthority to /root/.Xauthority do an xauth extract myfile as user and an xauth merge myfile as root. Myfile may be '-' for stdin/stdout.

Now let the following code in my .bashrc slowly melt on your tongue:

establishing users for a chroot environment

Now before we can use xchroot as user we also need to create these users in the chroot environment. Otherwise they would not be known in the chroot evoking several errors when you tried to chroot as user.

If desired you may add additional groups with usermod when xchrooting to the new root.

Effective group membership will not change unless you start a new session f.i. by invoking bash or xchroot. Check this with id -a.

xchroot and changeable media

Often you want to mount changeable media in the host system and get them become available in the 'guest' chroot. The -d option carries all mount points under /mnt and /media with it. The -p option additionally looks for mount points under /home. If you want all mounts issued after invoking xchroot to be constantly propagated to the chroot use the -w option for /mnt and /media and -n to additionally include /home. xchroot also allows to specify any directory of desire with -o/--once and -m /mydir1:/mydir2. To mirror mounts from within the chroot to the outside as well as to mirror in both directions see for extended options in the man page (-b,--mirror-out).

xchroot and read only roots (aufs,unionfs)

xchroot is also handy if you wanna leave your target chroot environment untouched for any kind of reason. This may be a necessity if your chroot environment is located on a read only media like your cdrom drive. Simply use the --aufs/-a or --unionfs option and be sure that either aufs or unionfs is installed.

Readonly access is established like this: Changed files are copied to /tmp/xchroot/{aufs/unionfs}-$rootname-$$ where $$ is the pid of the invoker and $rootname the name of the directory you are chrooting-into. The mount point of the two combined directories (ro+rw) is /tmp/xchroot/mount-$rootname-$$.

It is a totally new feature of xchroot-2.3 that you can also save the temporary changes you have made to your chroot-environment into a squashfs-image. Squashfs images for unionfs and aufs will differ in the naming and storage of whiteout files. Whiteout files are hidden files that make a file of the ro-root appear deleted. xchroot will ask you for unsafed changes on exit; optionally you can specify the --save my-unionfs.squashfs --noask options to make that automatically and prevent any direct user interactions (keyboard usage). Use the --restore option on a saved image:

When restoring elder changes an additional ro-branch mounted under /tmp/xchroot/squashfs-$rootname-$$ will be established. You may need to know about /tmp/xchroot whenever you issue a killall xchroot because then it will terminate immediately after listing the processes still running in the chroot-environment without performing the standard cleanup tasks. Do not kill these processes manually; use xchroot [--aufs/--unionfs [--restore xy]] cleanup $rootdir instead. It is recommended to specify the same options as before by only adding the keyword 'cleanup' before your root directory.

When using aufs you may want to mount /tmp or /tmp/xchroot to a tmpfs in ram especially when you are using a SSD or flashdisk because aufs needs some volatile files like the inode translation table. If you do not want to pack your changes into ram then you may want to use --unionopts xino=.. to relocate the inode translation table to a proper ramfs. Caution should be given with tmpfs. It makes the inode numbers wrap around if many files are created and deleted which can make aufs err. At the time of publishing xchroot it was not known if ramfs was affected by a similar problem.

If you wanna be absolutely sure not to confuse aufs you may also create an ext2 image in ram and mount it to /tmp/xchroot.

Note that some kind of partitions like ext4 partitions are not mountable if burnt to read only media because they seem only having been designed for rw-media always writing the last mount time. If you want to burn a root to blue ray in order to access it later on with xchroot use ext2 or JFS a fully fast and compatible filesystem also supported by OS/2 and eComstation

audio support for additional users 🔊

You may want to run programs with different users in one session and still have audio support. Usually the pulseaudio daemon that shall be contacted is read from window properties of the root window; see xprop -root | grep PULSE. This will not work if you have programs of different users that run in one session with the same root window. You will normally need one pulseaudio daemon per user because of the access rights. Fortunately there is also an environment variable PULSE_SERVER that you can set to /run/user/$(id -u)/pulse/native. Though this path is a default, check if you need the environment variable.

It may be best to start /usr/bin/pulseaudio [--daemonize=no] as the desired user before invoking xchroot because /run/user/NNNN/pulse will be exported automatically to the chroot. Pulseaudio alone can´t establish audio access without Alsa so again make sure that the user at best inside and outside the chroot are members of group audio. If you want pulseaudio to be started inside the chroot check your configuration in /etc/pulse (last section) and enable autospawn twice. If it complains about module-console-kit disable it in /etc/pulse/default.pa. If the daemon does not start automatically see what error messages pulseaudio --start will give you.