Revision as of 20:07, 4 June 2011

Process to configure the secure ASL kernel for X

Note: All these commands must be run as root. To become root, run this command "su -". The command "su" does not log or change an account into the root user, it just gives that user root privileges, which is not the same as "becoming root" and will cause all sorts of things not work correctly.

If X is already working for you, skip to step 4.

Step 1: Make sure you have X working first.

If X is not working on your system already, boot into a non-ASL kernel and setup X. This how to can not possibly cover every possible issue involved in getting X to work, so please contact your OS vendor if you do not know to install and configure X.

I'll try to provide what help I can in this step, but this is way beyond an ASL issue to get X working. So please contact your OS vendor if can not get X to work with a non-ASL kernel.

First, if you did a minimal install, you are likely missing a lot of components X needs to work, and I mean a LOT, so be prepared for hundreds of packages to be installed. If this sounds like your system, then you will also need to make sure you have all of X installed and working before you try to use X with a secure kernel.

If didn't do a minimal install, and you don't have X working now, then you are also likely missing a lot of packages. X is a very complex piece of software and you need lots of things to make it work.

So, if you do not have X installed, you will need to install the entire group. And if you aren't sure, run this command too:

yum groupinstall "X Window System" "GNOME Desktop Environment"

or if you prefer KDE as opposed to Gnome:

yum groupinstall "X Window System" "KDE (K Desktop Environment)"

This will install a lot of packages (see the comment on resources that X uses below, you can probably add disk space to that list too) and may take a long time, be patient.

During the install, X may start - don't reboot the system yet! Check to make sure yum is actually finished. To get the system back to the console, hit the keys "Ctrl+Alt+F1". This will take you back to the console where your yum groupinstall should be still running. Keep an eye on the yum process to make sure it finishes. Its likely to be only about 1/2 to 2/3rds thru the process at this point.

You may also want to install some other groups like "Graphical Internet" if you want to do other things with X, or just use the graphical installer from inside X to install software.

Again, if you have issues getting X to run, please contact your OS vendor. (Its their software afterall)

Step 2: If you do not have X setup to start on boot (or if you do have it installed but X does not start on boot), check the run level of your system and make sure its set to 5.

This means you need to change your runlevel in /etc/inittab from 3 to 5:

This line:

id:3:initdefault:

Needs to be changed to:

id:5:initdefault:

Step 3: Make sure for level 5, you have all the necessary X11 services enabled (check with your OS vendor if you are not sure, in Centos those are):

haldaemon messagebus (you might need "avahi" as well)

Step 4: Either log into the ASL GUI and change SYSTEM_TYPE (or from the command in /etc/asl/config) to "custom" and save.

Now reboot the system and make sure X is working for you. If you still can not get X to work, and you are using a non-ASL kernel, check to make sure you have all the processes running

Step 4: Allow privileged I/O on the system. Append this to /etc/sysctl.conf

kernel.grsecurity.disable_priv_io = 0

Step 6: Allow kernel module loading, again log into the GUI or from the command line change in /etc/asl/config

From

ALLOW_kmod_loading="no"

To

ALLOW_kmod_loading="yes"

(You will probably need to allow dynamic runtime module loading for various video drivers which may not load on boot, if yours do, then reenable kernel module protection by setting this back to "no". Its a pretty big hole, so if you can close it, please do!)

Step 7: And then reboot the system into the secure kernel.

reboot

Reasons not use X11 on a server

Reason 1: You probably don't need it on a server.

You can do pretty much anything you can do from X11 from a command line, remotely, and you can even run GUI apps from the server without running X. (I cant think of anything you can't do, I dont run X11 on any of my servers and havent found anything I could do, but maybe someone can think of something, if so - I'll see if I can tell you how to it without X!) So why bother having yet one more thing to support or worry about if you don't have to. Reason 2: X11 uses a resources you can use for other things, like memory and CPU.

More the former than the later, but both take a toll on the system. So if you run X on a box, you will have less resources to do other things. For desktop, this is a no-brainer - you need X11. For server, if you disable X11 your system will have more memory, and more CPU cycles to do real work. So for a server, this is free memory and CPU cycles! Reason 3: The big reason not to run X11 on a server is Security.

To run X11 you have to allow your system to do things that can make it very easy to compromise a server. For a server, with untrusted users (that is anyone you wouldnt give root to), its very insecure to run X or to even allow it to be run.

For a desktop, with one user, and no exposed services (like a web server), you are mostly fine because all your users generally have root (so who cares if they can get root, they already have it). For any system with outside users (people you dont want to have root) you are taking a big risk with X. X needs to be able to do all sorts of privileged things to just run, so its a pathway to root thats easier for someone to exploit. This isn't to pick on X11, all the OS GUIs (Windows, MacOS, etc.) need those same kinds of privileges to work. And for a desktop system that makes sense because you already control the hardware so you can do anything you want to the system, and you should be able to.

Unfortunately, all those privileges can lead to a root compromise. So, for a system with untrusted users (like a web server), running X is going to open the system up to all sorts of attacks and given that you an do anything (including running GUI applications from the server) without running X, in most cases its an unnecessary risk.

So, to summarize, as a desktop, running X is probably fine. Again because you trust you and you already have root, so its not a big risk (of course, something malicious could compromise the system thru X, but the user isnt malicious then its less likely). However, if you have users on the same system that you don't trust, and its possible to run X on the system (or worse, its running), its possible they may be able to gain root a lot easier than on a system without those holes.

ASL, by default, will close these holes and will disable X to prevent this from occurring. If you enable X, ASL will report that as a vulnerability, along with privileged I/O being allowed.