Sandboxing - Why it doesn't Exist in BB10 - or Anywhere Else

Sandboxing. What is it really? Does any system really give us what people think of when they're told "don't worry, it's sandboxed" ?

What is it about a sandbox that provides security of those inside from what is outside, or the other way around? Nothing really.
Attachment 247722

A more apt analogy might be a playpen.

Attachment 247724

But even this does not provide an real security. A person who gains entry to the house with the intent of doing harm to the baby won't be hampered by a playpen. The baby will have toys inside the playpen. She might throw them out, knock over a lamp that burns the carpet. In the worst case scenario maybe the house burns down. That doesn't mean a playpen isn't of some use. Outside the pen a baby could innocently wander around and fall down stairs. Or enter the kitchen and get burned.

But when we apply the idea of sandboxing to software as a security tool it is immediately compromised by the fact that we want the program contained in the sandbox to still perform useful functions (even if that is to entertain us with a game). To do that input must be routed from the user interface into the sandbox. Output must be routed from the sandbox to the user interface. The program might need to write on file storage, access the network, find someone in the contacts list, dial the phone. By the time we have made our sandbox into a place where useful work may be done, there are so many punctures in the perimeter that we might as well not have bothered.

So what do we do instead? The answer is white listing. You only allow software to run that has been examined and, to some acceptable level, been demonstrated not to behave in a malicious way. All modern smartphones do that to some degree by using their application markets to create a curated ecosystem. This is a fairly gross level of control, but it can be fine tuned by giving fine grain permissions that allow or deny access to various sub-system and APIs. Some permissions may be available only to the device maker, or a few select and trusted third party developers. Some may be more widely available to developers who can justify their use. Some may be controlled by individual users. BlackBerry (and others) has used all of these methods, though arguably BlackBerry was late to the game with their application store front.

In fact, if this Register article is to be believed (and I can find no reason not to), there is very little difference between how an Android application and a BlackBerry 10 native application are treated on the device. In fact as a developer I could write a flashlight application that steals contact data as easily on one platform as on the other. I could also write an application that tried to gain elevated permissions by manipulating bugs in the kernel interface on one as the other. There are some compelling reasons why I would be more successful on an Android device than a BlackBerry 10 device however.

So when you read or hear someone talking about the sandbox and how it makes it OK to run applications, take that with a large helping of salt. If the OS is well written, then it is much less likely that the device will become "infected" with Mal-ware. That does not mean a malicious developer could not make your life very difficult. An application with access to your contacts list, could steal data for spammers and telemarketers. One with access to the telephone system could make calls to premium rate numbers, or send premium rate SMS messages. An application with access the files on the device could do what Cryptolocker has been doing to desktops. As the "internet of things", cloud storage and ubiquitous computing integrate our devices more tightly to each other these are the things we will need to guard against. The sandbox, even if it ever existed, doesn't really help us with that. Ask yourself: where did this application come form, and who has looked at it to ensure it does what it claims, and no more? And: does this application really need all these permissions?

I think android apps run in a sandbox on android.

You make some good points, however, without knowing BBRY's operational defintion of "sandboxing", it is difficult to affirm the legitimacy of the weaknesses you mention. You have raised a very interesting subject and one that I hope will receive the kind of informed technical input from those-in-the-know who can shed some more light on the issue..

Originally Posted by kbz1960

I think android apps run in a sandbox on android.

Android applications (in the main) run on a virtual machine. Virtual machines may provide sandboxing, but don't have to.

Let's take the Cryptolocker attack, as an example. The attack generally takes the form of a targeted email with a specially crafted attachment that could simply be an executable masquerading as something else, but usually exploits a bug to get arbitrary code execution on the machine. The code executed finds all attached disk drives, physical, logical and network, searches them for valuable file times (documents, pictures, videos, etc) and encrypts them. The user then has to pay a ransom for the keys to decrypt and regain access to those files.

One way to protect yourself from that is to run your email client in a virtual machine with no access to physical or other disk drives. If you are attacked the damage is contained to the virtual machine. However problems arise when someone sends you a document you want to store. You can store it in the virtual machine, but there it will be vulnerable to future attacks. If you provide the virtual machine access to disk storage to store the file, then that storage is vulnerable. There is always some trade-off between security and usability.

Applications in Android, and other platforms, may need to access storage, contacts, the network, etc. These are controlled by permissions. If you withhold all permissions from an Application so that it can't access storage, contacts, the camera, network, or anything else, you may be able to say it is truly "sandboxed", but it might not be able to do anything worthwhile.

This is why just running any program and hoping the sandbox will protect you can be a dangerous practice. Many applications ask for permissions, most genuinely need that access and are intent of malicious activity. But some are. You may install them and give them the permission they need to do harm, because they ask for permission.

Interesting points, I do think people see sand boxing as a silver bullet so believe they aren't at risk.


Sent from my iPad using CB Forums mobile app

The permissions granted to native BlackBerry 10 apps can be altered, you can deny all permissions if you like.
However most apps you just would not want to opperate in their own private bubble.
From what I understand of android theres a secure linux base at the bottom with android sitting on top where all your apps run in one big DMZ. So while the core os is secure this seems to make little difference as all the stuff that means anything to the end user is exposed.
The situation with ported android apps in bbw seems to be alittle confusing.
Regarding the android runtime it would be nice to have a developer mode setting for this where it would be possible to turn on and off various rights to all android apps. That would be nice, and not hard to do although I doubt that would ever happen.

Can malware that attacks files affect cloud storage (e.g. Dropbox)?

Posted via CB10

Originally Posted by ALToronto

Can malware that attacks files affect cloud storage (e.g. Dropbox)?

Posted via CB10

I'm not familiar with how Dropbox works, I use Box instead, so my answer will be general . If Dropbox, or any other cloud storage application exports an interface that other applications can use, such as making your cloud appear as a directory in the shared storage, then yes a malicious applicatiomn that had access to shared files could do some nasty things to your files there.

BlackBerry has implemented some interesting mechanisms that develops may use to give the user access to the features but maintain security.

Let's say Dropbox wanted BlackBerry users to be able to save pictures from the camera, photo editor, what ever, onto the cloud. They could do it by registering to accept shared files. Except that instead of posting the file to social media they would copy (or schedule to copy) the file. This way the kernel handles the file transfer between apps, but the user is involved.

Posted via CB10

With Dropbox and Box, only those files and folders that you want to share are shared. The rest are visible only to you. But yes, both cloud services set themselves up as directories in the device's or computer's file system, so if you set them up without additional password login, they are visible from within the device.

Posted via CB10