Yes, I read Eric's blog. He's being disingenuous by claiming that while SELinux might have allowed a local user to escalate privilege, it would have been more resistant to a network attack. That might have been true in July, but it wasn't true in early August when this exploit was reported.
Having patched my kernel to 220.127.116.11 in July, this exploit would not run, with vm reporting that the page couldn't be mapped.
The problem is that SELinux is too difficult to configure forcing even quite knowledgeable sysadmins to rely on canned distro configurations, which may or may not be suitable for their particular need. In many situations (where WINE was needed), SELinux _was_ doing the right thing.
The same can be said of the hal, console-kit and policykit consortium. I'd feel more comfortable with an X server running as root, than the new unprivileged X, with hal and friends. The only way I can configure hal is to google a magic invocation and cross my fingers. I'll bet we'll see major exploits using hal, ck and/or pk coming soon.
I'm not sure what the solution is. My work around is to avoid any security solution that I can't comfortably configure and feel that I understand fully what I'm doing. That's never been the case with SELinux. I know there's a parser that will look at the logs and give you a configuration snippet, but I don't know how it works and so I don't trust it.