that you take that risk into account and live with it. instead of burying your head in the cushy cloud of false sense of security.
> That we give up implementing *any* other security mechanisms until, what?
security mechanims obviously must be implemented (you may have heard of intrusion prevention systems? such concepts are equally applicable to kernel land as well). fake mechanisms should not be, and especially they should not be presented to the gullible public as something they are not. both SELinux and this sandbox fail fatally if the threat model includes arbitrary code execution (which is what James Morris said). and of course you can prevent arbitrary code execution with much less than the overly complex SELinux. unfortunately such environments are less than usable for the average person, so this problem is far from solved.
> but at least can be proven secure more easily...
no they cannot. for any non-trivial system (read: something you'd actually install and use on a daily basis as you do now) the complexity of the code that solves our problems cannot be really reduced (that's why microkernels, hypervisors, 'solution' du jour are not more secure either).
> and then realise that SMM holes and FireWire's lovely remote-DMA
> features mean that we're *still* insecure...
SMM 'holes' are irrelevant in the real world as exploiting/abusing them requires privileges that you want to get in the first place normally. firewire et al. imply a different threat model (hw) and hence different solutions (physical protection, nothing unsolvable there if you can pay the price).