Slashdot Mirror
2010 Will Be the Year of Sandboxing Apps
Trailrunner7 writes "In a guest editorial on Threatpost, Mac hacker and security researcher Dino Dai Zovi writes that 2010 will be the year that software vendors get religion about sandboxing untrusted data in desktop apps. 'Instead of the usual top ten lists that are all-too-common with predictions for the new year, I have just one: 2010 will be the year of desktop applications handling untrusted data in sandboxed processes, and it will be about time. The largest Internet security threats now arrive through malicious web pages or e-mail attachments. This is because attackers are opportunistic and these are the weakest links especially because they easily pass through every firewall. Security is not and never was about SYN packets, it is about data: the software attack surface that attacker-controlled data interacts with and what sensitive data the attacker can get a hold of if they can exploit vulnerabilities in that software.'"
.. bloat.
Just look at how slow IE8 is to use.
Maybe we should just stop using the goddamn browser as an operating system. It was never meant to be anything more than a way to view mainly static documents, and quickly access other linked documents.
While some interactivity is of course useful and sensible, some fools have gone off the deep end and think we should treat the browser as some sort of an application development platform.
Of course, anyone who has done real application development under a real operating system, even if it is just Windows, knows how poorly the browser is as such a platform. It's clear that everything, from JavaScript to AJAX to Flash, has been tacked on as a shitty afterthought.
The answer isn't sandboxing. The answer is that we need to go back to using the browser as just a browser, and nothing else. And any real applications that demand network connectivity should be written as such, and run outside of the browser.
All security problems are easy to solve if you have users who are sophisticated about security, and motivated to put up with inconveniences. The real world isn't like that.
A proposal like this inevitably requires that the user understand something about the sandbox, and also requires that the user go through various hassles because of the sandbox. They're going to perceive it as a hassle, because the sandbox is going to prevent them from doing things they would otherwise have done. If they're unsophisticated and unmotivated, they'll just see it as something to work around.
Not only that, but this isn't an optimal solution. A flash game has to be a Turing-complete program. A memo doesn't have to. The simple solution is just to stop embedding Turing-complete programming languages in file formats that don't require them. Adobe actually started by designing postscript as a Turing-complete language. That had some unfortunate consequences, since, e.g., you can't predict whether a program written in a Turing-complete language will halt, so in principle you can't predict whether a document will take forever to come out of the printer. The realized that that was a mistake, and when they designed pdf, they intentionally made it not Turing complete. Now we've come full circle, and they've added a Turing-complete language, javascript, back into pdf. That's just bad design. The solution for users is actually pretty easy: if you're using Adobe Reader, turn off javascript.
Find free books.
.. bloat.
Just look at how slow IE8 is to use.
What does this offtopic post have to do with sandboxing?
Yes. Linux has many, many things that are pretty cool.
Unfortunately, they haven't had a good all-together tied-in user experience.
Claiming things like "we have chroot" and "we have sudo" and other code/geek-ish type of coolnesses is like claiming that your car has awesome engine with new piston technology, very secure door locks, and can run on almost ANY fuel currently available; unfortunately, the seats are rather uncomfortable and the controls on the dashboard look more like a commercial airliner's cockpit.
Yes, I know it's getting better. That's good. I hope they keep it up and continue to improve issues that apparently many geeks don't care about and many average users do (like flash video [youtube] and audio) and being able to use their iPods and scanners). :)
Security is about everything, period.
http://www.masturbateforpeace.com/
Sandboxing is a decade late, we should be so much further by now.. dang.
Storm
"unless you're using SBS " or run unix/linux " most organizations will only run Exchange or SQL or one major app on a server"
There, fixed it for you. Curiously unix can generally cope with running more than one app/DB without falling over or having one app
screw up the other.
"we even put all the third party database drivers on a separate server so as not to cause any potential issues."
Well that sums up running a Windows server doesn't it.
This isn't a Windows specific problem. The fundamental problem is the user/process model that's been popular since the inception of UNIX (maybe even earlier, I don't know enough about Multics to say): the idea that only users have identities and programs run under the identity (and permissions) of the user who runs it. If I'm running a game, there's no reason why it needs access to my tax spreadsheets, etc...
All software should be running under its own identity and access to user documents should be through standardized user interfaces... i.e., the 'File Open' dialog is actually a part of the OS not the application, and also grants temporary permissions in addition to just selecting a file.
We talk about the principle of 'least privilege' but in practice (with a few notable exceptions) the 'low-privilege' processes have the most important privileges of all: access to all our stuff.
Sandboxing only needs to be done right once. Validating user input needs to be done right every time. I'm not saying don't validate your user input, but if your first line of defense is a fairly brittle mechanism, having extra protection is a good thing.
Not true.
All of these systems are designed to protect users from each other on a single system, when a computer was an expensive resource. It's just that unix had a good multi-user single-machine design long before windows did.
But the threat model these days is running untrusted code from the network. Very few machines actually have more than one user on them - they all have their own machines. And all of that code is running with the full privileges of the user, with access to all their data.
That is the. problem these days. And it's not one that unix is any better at solving than windows is. I would add that I've used Ubuntu as my primary desktop for the last 4 years - I'm no Windows fanboy - but neither am I blind to the security weaknesses of my chosen operating system.
Sandboxing means that once the attacker has used an input exploit to own the process, it has to perform a privilege escalation exploit to get out of the sandbox. The problem is that applications running in sanboxes have to be able to write files, read files, load and install plugins, execute helper applications, and generally do just about anything a regulat application has to. So the sandbox can't be very "strong".
That's not really sandbox's fault, so much as the way that people design and run their OS. FreeBSD for example has the ability to combine flags and securelevel to prevent any changes to files that are so marked at all. It can be a pain in the ass, but it makes it very difficult for somebody to remotely install something to run at boot time.
Additionally, a proper sandbox shouldn't allow one to write to any portion of the hard disk that's directly accessible to the OS, and should really require exporting the information through the sandbox to access outside of the sandbox. If you're allowing the sandboxed app to operate directly on the disk you're doing something wrong and that area of the disk probably shouldn't be directly accessible except through a utility for doing so.