BUILDING THE XACE-SELINUX BRANCH 1. Set up your Build Host You need the following packages installed beforehand. This list is from a Fedora box; install the equivalent for other distros if you're not using Fedora. The ccache package is not strictly necessary but speeds up compile times significantly. gcc ccache automake autoconf imake flex bison libtool zlib-devel xmlto tetex docbook-dtds xml-common openjade freetype-devel fontconfig-devel expat-devel gcc-c++ libpng-devel ncurses-devel audit-libs-devel openssl-devel graphviz hal-devel In addition, you need a very recent version of libselinux installed. You could try the libselinux-devel package, but I compile and install libselinux directly from the Sourceforge SVN upstream. It does not matter if your build host already has an X desktop installed on it. In fact, you'll probably want this so you can test the SELinux-enabled X server by running the desktop applications on it. The build scripts will install the new X server into /usr/local or another path that you choose, so nothing will conflict. Finally, you will probably need a second machine that you can use to ssh into your development machine, since when the X server crashes it's usually not possible to get back to the console. 2. Decide where you will Build From and Install To On my development machine I keep all the X code in $HOME/git and build it there, and install to /usr/local. I set the ownership of /usr/local to be owned by myself, so I don't need to be root to install things there. The scripts will assume this setup by default. If you wish to change it you can do so (as described in step 4) but make sure the install directory is writable by you. IMPORTANT: Make sure that your /etc/ld.so.conf configuration has the install directory in it so that it takes preference over the system libraries! You need this so that the new X server doesn't try and link with the wrong libraries. Add /usr/local to the files, and run ldconfig as root. 3. Unzip the Tarball Change to your home directory (or wherever) and unzip the tarball. This will create the git/ directory with various subdirectories and files inside. This is where all the X source code will be stored. 4. Update preferences Edit the file do_common.pm and change the settings under CONFIGURATION as desired. You can change the options to the configure scripts by editing the hash values in this section. You may want to turn off some of the unneeded stuff in the xserver config options; I have them enabled for testing purposes. 5. Download the source Change into the git directory and run "./do_fetch.pl". This will go out and checkout all the sources from upstream (you obviously need Internet access to do this). If you get any "Operation failed" errors, e-mail me. This will take a while since there are so many separate modules. The script will also take care of switching to the XACE-SELINUX branch. Note that not all of the upstream source is downloaded. None of the sample applications are downloaded, and only a basic set of drivers. 6. Build the source Change into the git directory and run "./do_build.pl all". This will build and install everything. The compile output goes in build.log in the git directory. If you get any errors, e-mail me. This will take a good long while. The argument to the do_build.pl script is a target for building. The targets are defined in the file do_build.conf. Each target consists of a list of modules to build. In particular, the "serverclean" and "serveronly" targets will rebuild just the server, and the "drivers" target will rebuild just the drivers. If you want to know more about the format of this file/how to add more targets, etc., e-mail me. NOTE: the drivers have an ABI dependency on the X Server. Since the SELinux work has broken the ABI, this means that you can't use the drivers that came with the Linux distro, you must use the ones compiled from source! It should "just work" so that the X server looks for drivers in the right place, but if it doesn't the symptom will be a segfaulting X server. 7. Build the SELinux policy This can be found in the "xselinux" branch of refpolicy on the Tresys OSS site. Instead of checking out "trunk" checkout "branches/xselinux". Build and load this policy. It should work in either strict or targeted. Note that the xserver binary, /usr/local/bin/Xorg or whatever, needs to be labeled with xserver_exec_t, and some other special labels are defined in the xwindows.fc file_contexts that should be set properly. 8. Configure the X Server The /etc/X11/xorg.conf file should be edited to match your system. I have tested with the simple "keyboard" and "mouse" drivers and the "vesa" video driver. You can edit the gdm configuration so that it starts the new X server instead of the system one. To do this, edit /etc/gdm/custom.conf and add these lines after the "[server]" line: [server-Standard] name=Standard server command=/usr/local/bin/Xorg -audit 4 flexible=true To change back, just replace the "command" line to point to the normal server. You can also configure startx/xinit to launch a different server. Check the manpages for these commands. 9. Run the X Server The server should start and run. Right now, AVC's are logged on the stderr of the X server as well as the log file Xorg.0.log. On my system the X server writes to /usr/local/var/log instead of /var/log, not sure if this is compiled-in behavior. In enforcing mode, things will probably break royally. The policy is still under development and apps typically do not handle errors from the X server gracefully. 10. Updating and rebuilding To update your sources from upstream, change into the git directory and run "./do_update.pl all". Again the argument to the script is a target, this time defined in do_update.conf, which defines which packages to update. Then go back up and run the do_build.pl script as described earlier. Again if you get any errors, e-mail me.