So on another computer forum I saw some references to AppArmor profiles for the Xorg setuid binary. Is this at all reasonable? AppArmor can restrict even root processes as long as they're not running in kernel mode, correct? Assuming the policies can be enforced at all, this actually does seem reasonable to me. Granted, someone who's hijacked the Xorg binary can probably sneak into any X11 client application, but if AppArmor makes that significantly harder it would still be useful. e.g. I believe Xorg doesn't actually have to launch anything directly, GUI applications are started separately as clients that communicate with it. And Xorg is not even multithreaded. So why allow the setuid binary to invoke fork or exec system calls? At least make it really annoying for an attacker to spawn a root shell. Likewise, there are a bunch of filesystem areas and devices that only client software should need access to, not Xorg itself, right? So why not block the X server from reading that stuff? On the other hand, the server can freely grab keystroke data and such from any client, and that is extremely hard to mitigate. So while not futile, even a working AppArmor profile for Xorg might not be as broadly effective as one would hope. I'm also interested in the possibility of sandboxing other setuid binaries. e.g. pmount does not need access to things like the screen device, audio devices, keyboard... And, again, it does not need to fork/exec anything.