One of the things SELinux has been used for is to reduce attack surface inside the android OS. Basically they found that number of vulnerabilities discovered seemed to be proportional to the number of kernel calls available. When the kernel adds a new improved call to do something, the old way is kept for backwards compatibility. Since they knew they had up to date libraries that didn’t use the old kernel calls, they used SELinux to block them. (there was a youtube video of someone giving a talk on this somewhere. I don’t know where though)
So that’s one example of what SELinux can do.
AppArmor people will say AppArmor is “just more course grained” then SELinux. Of course they don’t mention what they mean by “Course grained”. One example of course grained would be a power switch. You disabled access to the legacy kernel calls by flipping the power switch. The same thing was accomplished, however now none of the other calls work, nor does anything else in the system.
Obviously AppArmor can be more fine grained then a power switch, but the point is that when they say “yes we can disable that, it’s just more course grained”, they mean that when they disable what you wanted, they will have to disable other things which will often disable the functionality of the program you were trying to run (meaning that you have to leave the feature enabled and not disable it if you are running AppArmor)
However, in practice, the real effort in using either is generating the profiles.
Also, there is a thread with someone successfully running SELinux (in a qube, not in Dom0), here:
Note that since the user isn’t supposed to be installing software in Dom0, that it should be possible to know which kernel calls are not needed, and they could do the same “kernel call attack surface” thing in Dom0 that android did. (assuming of course that they had unlimited time to do so)