Difference between revisions of "X with ASL"
m (→Reason 1: You probably don't need it on a server.) |
m (→Reason 3: The big reason not to run X11 on a server is Security.) |
||
| (3 intermediate revisions by 2 users not shown) | |||
| Line 58: | Line 58: | ||
= From this point forward you should have X working = | = From this point forward you should have X working = | ||
| − | '''Step | + | '''Step 5: Allow privileged I/O on the system.''' |
| − | + | Again log into the GUI or from the command line change in /etc/asl/config | |
| + | |||
| + | From | ||
| + | |||
| + | DISABLE_PRIVILEGED_IO="yes" | ||
| + | |||
| + | To | ||
| + | |||
| + | DISABLE_PRIVILEGED_IO="no" | ||
| − | |||
'''Step 6: Allow kernel module loading''' | '''Step 6: Allow kernel module loading''' | ||
| Line 90: | Line 97: | ||
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. (We cant think of anything you can't do, We dont run X11 on any of our servers and havent found anything we couldnt do. So why bother having yet one more thing to support or worry about if you don't have to? | 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. (We cant think of anything you can't do, We dont run X11 on any of our servers and havent found anything we couldnt do. So why bother having yet one more thing to support or worry about if you don't have to? | ||
| − | == Reason 2: X11 uses | + | == Reason 2: X11 uses 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! | + | 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 a Linux desktop, this is a no-brainer - you need X11. For a 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.== | == Reason 3: The big reason not to run X11 on a server is Security.== | ||
| Line 100: | Line 107: | ||
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. | 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) | + | 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 can an do anything without running X (including running GUI applications from the server), in most cases its an unnecessary risk to run X. |
| − | So, to summarize, as a desktop, running X is probably fine. Again because you trust you and you already have root, | + | So, to summarize, as a desktop, running X is probably fine. Again because you trust you and you already have root, its not a big risk (of course, something malicious could compromise the system thru X). 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. | 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. | ||
Latest revision as of 15:09, 11 May 2020
Contents |
[edit] Process to configure the secure ASL kernel to run X11/Xorg
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.
Note: This step is provided as a courtesy. X is not part of ASL, its part of your operating system. If you can not get X installed on your system, please contact your operating system vendor.
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.
First, if you did a minimal install, you are likely missing a lot of components X needs to work, and we 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. On Centos, Redhat or Fedora the command is:
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. If this does not work for your system, contact your OS vendor. Getting X working without the secure kernel is not an ASL issue.
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 after all)
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/Redhat those are):
- haldaemon
- messagebus
- avahi
Step 4: Change the system type in ASL to "custom"
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 into a non-ASL kernel 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 and all of the necessary X component installed. At this point, with ASL in the "custom" mode, it will not disable any services. Furthermore, if you are not running the ASL kernel, you can rule out ASL as the cause of any issues with X starting. Please contact your OS vendor for support with starting X
[edit] From this point forward you should have X working
Step 5: Allow privileged I/O on the system.
Again log into the GUI or from the command line change in /etc/asl/config
From
DISABLE_PRIVILEGED_IO="yes"
To
DISABLE_PRIVILEGED_IO="no"
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"
Note: You will probably need to allow dynamic runtime module loading for various video drivers which may not load on boot, if yours do, then re-enable 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
At this point X should be working with the ASL kernel.
[edit] Reasons not use X11 on a server
[edit] 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. (We cant think of anything you can't do, We dont run X11 on any of our servers and havent found anything we couldnt do. So why bother having yet one more thing to support or worry about if you don't have to?
[edit] Reason 2: X11 uses 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 a Linux desktop, this is a no-brainer - you need X11. For a 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!
[edit] 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 can an do anything without running X (including running GUI applications from the server), in most cases its an unnecessary risk to run X.
So, to summarize, as a desktop, running X is probably fine. Again because you trust you and you already have root, its not a big risk (of course, something malicious could compromise the system thru X). 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.
