Linux Unhackable At TippingPoint Contest (eFluxMedia)

Yeah. It's called a JVM.

What you get then is security holes in the JVM.

(They're still turning up, after fifteen years... I suspect anything 
complex enough and with enough interfaces to the outside world to run a 
useful plugin on top of will be complex enough to have a never-ending 
supply of increasingly baroque security holes.)

A virtual machine isn't necessary.  SELinux can confine processes and only allow them do
things that are specified by the policy.  People are working on policies for browsers but it
is hard because users want browsers to support downloads and uploads.  Plugins would need to
be run in a separate process to be more limited than the browser.  This could be done with
nspluginwrapper.  Some plugins, like Flash, will need access to the network.  Some might need
access to files but probably could be limited to a single directory.  In any case, they could
be prevented from accessing arbitrary user or system files.

X would still be vulnerable to attack since plugins talk to the X server.  There has been some
work on adding SELinux to X.

The Linux kernel can also be vulnerable to root escalation exploits.  Some can be done before
the SELinux hooks or with calls that aren't checked because they aren't normally a security
problem.

A Linux process already runs in a virtual machine: it sees a virtual address space, a
virtualized processor and no direct hardware access.  The problem is not lack of
virtualization, but too much permissions given to the process running in the virtual machine.
Browser plugins could be run in a sandbox giving them no access to the filesystem and only
limited network access.  I suppose setting up a VMWare instance, etc. is one convenient way to
get this, but it seems like unnecessary extra layering when SELinux, chroot and so on can
achieve the same effect in a more lightweight way.

There were quite a few posts on Slashdot claiming that the Vista Internet Explorer did exactly
that for either the entire browser or for the flash plugin, but apparently it failed to stop
the attack. It sounds like Flash actually ran another executable outside the sandbox that
opened up a communication channel with the sandboxed part and obeyed instructions from it. Not
at all clear whether this outside executable was either setup to autorun as part of the flash
installation, or if somehow the "sandboxed" flash was still able to cause it to run.

If there is any truth to this it is a good indication that reliance on sandboxing to solve
things may be wrong.

On my single user machine.. aka Laptop.. I am much more concerned about protecting private
data such as online passwords, financial stuff, and links to banks and that sort of thing. Any
sort of information leakage that can put me in a vulnerable position.

As far as I am concerned what I have in my home directory is much much more sensitive then
what I have in my.. say.. /etc/shadow file. My /etc/password file could be containing plain
text passwords and it wouldn't make any difference.  At that point I don't really care, the
game is already over.

So if they get through my browser and into my main account then I am screwed. There is no need
for a root exploit.. the damage is already done. They got access to the vast majority of my
sensitive information.

The only advantage I have then for protecting my root account is that user applications are
much easier to detect then your average linux kernel module root kit. Even then it's still
better to wipe and reinstall. That approach requires much less effort.