I didn't misunderstand you but you don't seem to understand the size of the TCB on a modern Linux system. Its massive and relying on proper auditing of the code is unreasonable. Some even argue that the kernel itself shouldn't be contained in the TCB.
If a malicious userspace binary can expoit a kernel vulnerability it doesn't matter what you do because its game over. You still seem to be missing the idea that protections at a given level can't protect that level reliably. SELinux doesn't claim to protect against kernel vulnerabilities. It claims to contain the accesses made by userspace programs and at best mitigates damage caused by an exploited application by confining the actions the application may take to only what it requires to run (assuming your policy is configured correctly). I'm talking about an exploit in a userspace framework allowing for attacks on other userspace applications. This is entirely reasonable considering its how attacks work today on systems that use simple DAC protections. Own a process running as root and do whatever you want including poke into the address space of other processes. You're trying to argue here that DAC protections are sufficient. This has been shown time and time again to be false. You might want to read up on the MAC vs DAC discussion to see exactly why they are insufficient. POSIX does not provide sufficient access control protections for any modern system.
Also with the exception of the mmap_minaddr bug which Brad found (and was subsequently fixed) SELinux does not grant permissions over your existing permissions. The LSM framework is designed to provide further restrictions not to act as a priviledge granting mechanism. So unless you've found an exploit in SELinux code which allows for arbitrary code execution or memory manipulation in the kernel I'm not sure what kind of buggy SELinux code you'd be referring to.
With respect to trusted path again there is currently no way to do this and relying on userspace to provide a mechanism for trusted path won't work. The fact that any number of components can be overwritten to trick you into typing a password in for an action that isn't the one you think you're authorizing makes that not possible today.