Slashdot Mirror
Chrome Throws Flash Into the Sandbox
wiredmikey writes "Google announced today that it will be extending Chrome's sandboxing technology to include the Flash Player plug-in. 'Sandboxing' technology is a method of isolating an application from the rest of the operating system and tightly controlling its resources. According to Google, the new sandboxing feature adds an additional layer of protection and will help protect users against malicious pages that attempt to hijack systems or steal information from the system."
That'll be helpful if it supports Flex-framework apps (which it should, given that they run in the flash player).
I've been developing a flex app for the Blackberry Playbook that's coming out in February; the ability to port it to the chrome store without much extra work would be handy.
In Xanadu did Kubla Khan
A stately pleasure dome decree
that Flash was 'as good as dead"?
http://www.geoffreylandis.com
You have to run it on a completely different machine. Can't get much more secure than that.
I'm assuming they are talking about Chrome the browser not ChromeOS
Not all life is cyber. Extra Income
It would depend on how much in resources is allocated to sandboxing. If this is a static number, then what if the flash is simply a flash banner ad and has resources allocated to it. Now, if the allocation is fully dynamic, this could be very awesome. They would still run into an inevitable problem of not enough resources on the machine, but then again, that is hard to avoid. I truly hope Google is not going to statically allocate resources since that would be bad. I have seriously made a logo for a person in the past using flash. If the resources are static for allocation, then there is a very High chance Google will either allocate too much or too little to something.
The world is how you make it
Google earns money through advertising and wants to serve Flash banners (As doubleclick, which is already owned by Google, does). All new security holes in Flash cause more people to block or at least hate it. By sandboxing Flash in Chrome, Google both encourages people to use its browser and lowers the motivation to block all flash content. A great decision for Google and it happens to benefit the users, too.
(As a freelancer who prefers Chrome as his browser, works mostly in internet advertising and occasionally teaches courses in web development related subjects - including Flash - I'd like to hug the engineers that implement this.)
In case you missed it, the Chromium Blog talked about this in their December 1st blog entry.
GLaDOS for President 2016! "Well here we are again. It's always such a pleasure." -- GLaDOS, 2011
After all, I already run Chrome itself in a sandbox. Firefox, too. Why?
Pretty much every exploit now begins by "the user visits a website". After that, pretty much any technology can be the hole it exploits - Java, Flash, PDF viewing, even JPEG rendering has been exploited. There's an abundance of targets. The modern browser is just too big a platform to secure completely. So, I don't trust any browser more modern than Lynx.
Original Slashdot story from December 3rd.
GLaDOS for President 2016! "Well here we are again. It's always such a pleasure." -- GLaDOS, 2011
Can the sandboxing be done in such a way that all the data written by FlashPlayer in local storage can be erased when it goes out of scope? Every invocation of flash player will be on a freshly cleared local storage and one flash run will not be able to retrieve cookies and other persistent data?
sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
This is most likely in response to their poor score in the NSS Labs report. Maybe their score will improve from 3%?
Er, no. That report evaluated performance against "socially engineered malware" only. In short, it tested how well the browser handled protecting the user from being careless or gullible.
Chrome's sandboxing is intended to limit the damage if an attack is encountered, not to keep the attack from happening by warning you that a given site hosts malware.
Don't tell me to get a life. I had one once. It sucked.
Heck, I think Firefox did it already... I think Flash must have released an unstable version recently. I’ve had Firefox lock up on me a couple of times. Killing the “plugin container” process in Task Manager immediately made Firefox start responding again and display an info bar on pages that had been using Flash saying that a plugin had crashed (gee, wonder why?) and suggesting that I reload the page.
Distributed Denial of APK: It takes 15 seconds to reply to him anonymously, but wastes tons of his time if we all do it.
would be to sandbox everything made by Adobe.
Litter box, sandbox; both are full of sand and "Tootsie Rolls".
No. This was actually announced 2 weeks ago by Google and Adobe, not today. http://blog.chromium.org/2010/12/rolling-out-sandbox-for-adobe-flash.html
If you browse in incognito mode does it then make all flash storage non-persistent? Because this is how the evercookie works across incognito.
Flash, ChromeOS, COBOL....
This is Slashdot - where unless it's tomorrow, it's yesterday.
"Lame" - Galaxar
I run my sandbox in a sandbox. That ought to be safe enough!
...we called this a "virtual machine".
You don't need a full VM though with a Modern OS. You can run a plug-in as a child process with almost no access privileges and then it has to request minimal (and hopefully secure) access API's from the host/parent process. This way the plug-in can't directly access file IO without going through an extra layer where it can be scrubbed and gated. Also, since it's running in a different process, it can not directly access any of the memory through pointers in the host/parent process.
As an admitted fan of the iOS line, that was comedy gold. Here's hoping the butthurt fanbois don't have mod points today.
Linux, you magnificent bastard, I read the fucking manual!
... a long time ago. I'm not impressed.
Perhaps I'm trolling, perhaps I'm not.
Unfortunately, Linux in this respect is not a "Modern OS". The ability to sandbox user applications is extremely poorly developed. I have been looking at portable sandboxing lately, and it is a horrible nightmare. The Chrome developers created some fancy hacks for each OS, and they have pulled it off quite nicely, but they remain hacks, not elegant designs. The platform with the best current sandboxing API is, ironically, Windows Vista/7, with their configurable integrity levels. An API dubbed "Seatbelt" is being developed on MacOSX, but it is still in its barely-can-walk infancy, and the Chrome devs used undocumented parts of the API to make it all work. On LINUX there is a set of competing security modules for the kernel, with SELinux being the most used. Unfortunately, not only do some distros not use it, but a lot of users who have it disable it immediately (or set it to permissive mode, which from a sandboxing point of view is the same thing). And SELinux is a horrible beast to program for. It is insanely complex, and has non-existent documentation on how to use it to confine user programs.
What is needed is some generally agreed upon extension to POSIX on how to easily allow a user process to drop privileges it does not need. One experimental OS I looked at once (VSTa) had the ability for all users to create subgroups to their GID by adding more numbers. If your UID.GID was 500.500, you could create a new directory owned by 500.500.2, and allow the process owned by 500.500.2 only to access to this directory (some documentation on this is still up at http://www.vsta.org:8080/VSTa_2fDocumentation_2fCapabilities). I wish some similar, dead simple scheme could be created for Linux that ordinary users could understand themselves. Only a dedicated security elite could possibly wrap their heads around the SELinux rules -- everyone else just turn it off as soon as it gets in the way.
I think Linux advancement in virtual machines has been advanced fairly recently.
The Android operating system is a linux based OS that runs java virtual machines, every application in a separate machine with their own database.
You have to manually allow interaction between programs... it is quite stable.
I steal signatures. This one used to be yours.
Since a sandbox is a literbox and a litterbox is really just a toilet. That would mean they're throwing flash in the toilet. Perfect!
If someone is passing you on the right, you are an asshole for driving in the wrong lane.
It couldn’t use hardware acceleration before. It can now. They’re releasing a new version that does.
I think you mean, Flash used to suck... and it wasn’t really entirely its fault.
Distributed Denial of APK: It takes 15 seconds to reply to him anonymously, but wastes tons of his time if we all do it.
I think this is a good step forward. I'd like to see the majority of plugins in a sandbox. I like to use them, but you can't always be 100% sure if you can trust them or not. Sure, there are applications that have been around for ages, are designed by good companies that have decent reputations - but what about that "must have app" that you're not completely sure about? I know on my Blackberry, each application has its own permissions. I can add and remove permissions at will, and even set them to prompt me. I've always found Internet Explorer a bit scary, but have never worried much about Firefox. With some plugins, it should be a no brainer: does a weather application need access to my hard drive, aside from a caching space? I don't think so. Possibly plugins could be vetted and reviewed by a committee, and given permissions within the browser/OS based on what they need to do, and each plugin would have a "safety rating" (red, yellow, green) so you can choose your exposure. If all of your plugins were "green," you'd know that the committee reviewed the code and set the permissions in such a way that your data could not be compromised. If code could not be reviewed, it would automatically be marked yellow or red. I like the idea of choice as equally well as I like safety and security.
The platform with the best current sandboxing API is, ironically, Windows Vista/7, with their configurable integrity levels.
They do say that necessity is the mother of invention.
The day they announced the Chrome browser they said they would work with Adobe toward this goal.
http://blindscribblings.com - Tasty pop-culture in conceptual fashion.
As opposed to the Unix world where a process can be associated with a user and a group and have fine-grained permissions based on the user and group, and then even more so with AppArmor, SE Linux, etc?
http://blindscribblings.com - Tasty pop-culture in conceptual fashion.
NT supports that and more. It's just that when you stray from the realm of filesystem and registry object ACLs, it becomes horribly nonintuitive, and things like process-based IPC security are up to the application to enforce (which, except for the 0.01% of programs such as Chrome, they never do enforce).
Though I vastly prefer the SELinux/AppArmor approach of using agglomerate text files for defining rules... but that might be because I'm a part-time programmer.
What is needed is some simple tool for configuring an SElinux profile based on an application's behavior. A very complicated tool exists but that is not so helpful.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Probably both.
that Chome was "as good as dead"?
That was ChromeBSD.
Does Netcraft confirm this?
To have a right to do a thing is not at all the same as to be right in doing it
It's the user who's in the sandbox with Google software. No chance of turning off the fade-in, or the instant search keylogger.
Something tells me the "we need monies!" department will trow a wrench in to the machinery.
The tracking cookies will not be blocked and thus there will be a way to "escape" the sandbox. Google is an advertisement company you know.
Disclaimer: I am a Google user. I am simply aware of their revenue stream.
Well, I might have a way, but it only works on a semi spherical planet in a vacuum.
ChromeOS, not Chrome.
I'm afraid that Flash performance might get even worse if they do this, though. Flash performance is already bad.
I am not devoid of humor.