| |||||||||||
Linux Unhackable At TippingPoint Contest (eFluxMedia)Linux Unhackable At TippingPoint Contest (eFluxMedia)Posted Mar 31, 2008 21:42 UTC (Mon) by eru (subscriber, #2753)In reply to: Linux Unhackable At TippingPoint Contest (eFluxMedia) by drag Parent article: Linux Unhackable At TippingPoint Contest (eFluxMedia) but ya certainly likely that nothing inherent in Linux would save us from some proprietary browser plugin eating our home directories or whatnot. You know, I have long wondered if it would be practical to sandbox those plugins into a virtual machine. Of course they all try being sandboxes unto interpreted code themselves, but they often have flaws. Putting the plugin itself into a virtual machine instance (built for the purpose and torn down after the plugin exits) would erect another wall around it. I'm pretty sure this is doable, but whether the performance would suffer too much is another question.
(Log in to post comments)
Linux Unhackable At TippingPoint Contest (eFluxMedia) Posted Mar 31, 2008 22:14 UTC (Mon) by nix (subscriber, #2304) [Link] 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.)
Linux Unhackable At TippingPoint Contest (eFluxMedia) Posted Apr 2, 2008 10:57 UTC (Wed) by dvdeug (subscriber, #10998) [Link] No machine is unhackable once you're sitting at the controls and the hacker has a gun to your head. The name of the game is never impossibility, it's making it sufficiently difficult that they give up. If the VM adds an additional layer, that can be a good thing (if it's worth the cost) without being perfectly free of bugs, so long as those bugs are fixed promptly.
Linux Unhackable At TippingPoint Contest (eFluxMedia) Posted Mar 31, 2008 23:25 UTC (Mon) by ianburrell (subscriber, #47313) [Link] 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.
Linux Unhackable At TippingPoint Contest (eFluxMedia) Posted Mar 31, 2008 23:36 UTC (Mon) by zlynx (subscriber, #2285) [Link] Yeah, SELinux can do it, or a set of alternate user accounts and sudo. On a laptop system, something like "sudo webuser firefox" can go a long way toward enhancing your browsing security without getting into anything too complicated. A virtual machine is overkill. I also find it a bit funny. After all, virtual memory and process isolation was supposed to protect us from all the same problems virtual machines are supposed to save us from now. All our current security issues are caused in the name of convenience, and now in virtualization VMware is already getting into security problems in the name of convenience (all their cut&paste and remote control options? potential security holes).
Intra-application security models Posted Apr 1, 2008 9:25 UTC (Tue) by skitching (subscriber, #36856) [Link] Interestingly, Java's security model means that different pieces of code within the same process can have different security policies. This is possible because instructions in JVM bytecode do not just address random bits of memory; they are constrained to access only valid objects. And a code verifier runs at load-time to ensure that they do so. So a browser implemented in java can apply a different security policy to plugins than to the IO code that interacts with remote webservers. Other languages can do this too; Microsoft's research OS "Singularity" applies a similar approach, allowing user code to run with the same privileges as kernel code - but the code must be written in a special "verifiable" language. Having only per-process security and then using multiple cooperating processes is an alternative, but has some major impacts on performance and developer convenience. I don't know why people are so harsh about Java and similar languages. There really are some nice features available when using a "constrained" language. Ok, it's possible for the VM to have a security bug; anything can have a bug (splice, anyone?). But I personally don't remember a major one for a long time in the Java VM.
Intra-application security models Posted Apr 1, 2008 18:56 UTC (Tue) by nix (subscriber, #2304) [Link] The verifier has had bugs with security implications, I know that. (Whether anyone ever *exploited* these bugs is a different question.)
Linux Unhackable At TippingPoint Contest (eFluxMedia) Posted Apr 1, 2008 10:40 UTC (Tue) by epa (subscriber, #39769) [Link] 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.
Linux Unhackable At TippingPoint Contest (eFluxMedia) Posted Apr 17, 2008 10:38 UTC (Thu) by lgb (guest, #784) [Link] Yeah, according to launchpad.net for example, one of the loudest desktop bug in ubuntu development distro is the flash problem (crashes the while webbrowser). In a sandbox, plugin would not be able to crash the whole browser and of course you would be able to enhance the security as well with applying verious restrictions to it, eg like my current solution where flash plugin is runned by nspluginwrapper even on 32 bit machine, it does the "browser crash protection" and also since plugin is running another process it does not slow down the whole browser and even cause better utilizition of multiple CPUs/cores of current desktops ...
Sandbox Posted Apr 3, 2008 21:19 UTC (Thu) by spitzak (subscriber, #4593) [Link] 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.
|
|||||||||||