You're quite wrong about SELinux; it _is_ part of the kernel. Admittedly it requires a policy to be built and loaded from userspace, but your "ACLs" would require some ACL utilities to apply those from userspace.That is true, but is it included in every stable release of the kernel (by default)? And why aren't more distributions using it (the popular ones - for example, I know Mandriva uses grsecurity).
In any case SELinux is an extremely powerful model; you can define your arbitrary RBAC+TE state machine and constraints, then the kernel applies it to your system; as simple (or horribly complicated, as the case may be) as that.And what are your feelings on SELinux still being "under research"? Can such a system be used in a production environment, when it has not been declared a completely mature system by its creators?
Here's a better security model: SELinux lets you give root access to everybody and still have a 100% secure system (although it's not really recommended). Google around for the public SSH-accessible SELinux testbeds with root's password set to "password" or "1234" or whatever and feel free to log in and have a look. Besides, we do have POSIX ACLs on files; if that's what you're looking for, but that's not extensible enough to cover processes too.A 100% secure system except for the files that sshd has access to, correct? If global access is allowed to root, but it is locked down to sshd, then anyone who logs in as root can only modify those files that sshd has access to... Or is there a part of the puzzle that I am missing? I had not heard of those testbeds before, but I would like to see how they are set up.