Thinking inside the box

Commenter Nick asks whether any though has been given to running applications in a sandbox where they are given access only to their installation directory, My Documents, and a handful of other directories and registry keys. "I feel that this would seriously prevent viruses/spyware from being as effective, and apps would not be able to dump files all over the users' HD."

Yes, a lot of thought has been given to sandboxing (most of which I am not at liberty to discuss) but the compatibility consequences have been a constant source of trepidation.

For example, if you restrict the application just to My Documents and other selected folders, then double-clicking a file from some other location (not on the list of "allowed" locations) would result in a strange "File not found" (or maybe "Access denied") error message when the application tried to open a file that it didn't have access to. Redirecting file system operations has its own problems, such as applications saying that they successfully saved the file, but when you go to look in Explorer, it's not there!

To add to the complexity, the Common Criteria (the modern version of what was formerly known as C2 security) have their own rules about what behavior is permissible. For example, it is my understanding that the Common Criteria require that when access is denied to a location, the error that is returned must be "access denied"; you are not allowed to lie to an application and say "Um... yeah... I got your location right here..."

Tracking an application's shortcuts and registry entries is complicated by the fact that the application is hardly the only entity that accesses those shortcuts and registry entries. If some other application moves the shortcut to a new location or copies it, does that get added to the tracking list? If so, which tracking list? (The one for the application that created the original shortcut or the application that copied it?) Many settings are system-wide. If an application changes a system setting, and then you uninstall the application, do you restore the system setting to the value it had before the application was installed? If you say yes, then what if you had five applications all of which were changing the same system setting, and you uninstall the third one, what do you "restore" the setting to?

Windows Vista introduces a limited sort of "sandboxing" as part of a compatibility shim for applications which write to administrative locations in the file system or registry for no good reason. Those writes are redirected to a "pretend" directory or registry key, and the application (hopefully) doesn't know any better. That's about the extent of my knowledge of this Windows Vista feature; if you want to read more about it, you can probably hunt around MSDN. Try the phrase file system redirection. (This will probably also turn up features related to 32-bit emulation, so you'll have to do some more filtering.)

Comments (32)
  1. David Mills says:

    What’s in the box?

    Sorry, I couldn’t resist.

  2. Pierre B. says:

    One way to circumvent these issues is to turn around and provide a sandboxing infrastructure and management but not any built-in sandboxing. Maybe only a few examples.

    Obviously, this is a IT-level feature, not a home-user feature, although one could see spring-up an after-market of pre-built sandboxes. VM are a type of such sand-boxing, but their approach is heavy handed and hard to use even once completely configured.

    Linux could be said to have something like this with SELinux, and we’ve seen how much it’s being used and customized by end-users… (answer: it’ too arcane to be used by mere mortals.)

  3. porter says:

    You will be greeted with howls of "Why can’t I just.." and "All I want to do is….", and "When I do this it works, but when I do this it doesn’t".

    So user’s have rights, should applications? Well we’ve given them to corporations so why not.

  4. R. Bemrose says:

    To some extent, 32-bit applications are sandboxed by WOW64 on a 64-bit system.  Where the real fun begins is that it does the registry different depending on whether you’re on Windows Vista or Windows 7.

    For example the MSDN article on Registry Redirection is flat out wrong for Windows 7.

    Said article:

    Why?  Windows 7 removes Registry Redirection:

  5. Sunil Joshi says:

    @ R. Bemrose

    [For example the MSDN article on Registry Redirection is flat out wrong for Windows 7.]

    Read the article more closely. (Hint search for Windows 7).

  6. Koro says:

    Windows Vista and 7 have Integrity Levels. It works quite nicely, and the fact that you have to manually set them with a command-line tools means you’ll know where to look if something goes wrong.

  7. "the compatibility consequences have been a constant source of trepidation"

    Vista won’t allow you to save things in the Program Files directory anymore, but instead of denying the write it silently redirects your files off to some other hidden directory.  For almost everything this just works, and you don’t need to know about it.

    However, one of my apps saved its output to the working directory by default unless you tell it otherwise.  I had a moment of sheer panic when I went to go look for all my output and it had EVAPORATED!!  Once I found the ‘compatibility view’ button, it was all clear to me.

    I understand why they did it.  I of course wish they’d done it differently, but I can’t honestly say I can think of a better way to do it.

  8. Alexandre Grigoriev says:


    You’re confusing WoW64 registry redirection (described in that article) and per-user registry and filesystem redirection (redirection of writes to protected system locations), which is what Raymond mentions.

  9. Eric Wilson says:

    Windows already has this feature.  Its called "not running as Administrator".

  10. Ben Voigt [C++ MVP] says:

    While something along these lines would be great, implementation surely would be difficult.

    First, reduce the problem (and therefore the diversity of cases which contribute to complexity of the solution) by getting rid of "must be running as admin to install anything at all".  Automatically considering installers "RunAsAdmin" was probably the worst mistake MS made with Vista, it did more than anything else to give UAC a bad reputation.  There’s no reason that some little currency conversion widget should need admin rights to install.  Same is true for every game in existence.  If corporations want to restrict what programs can be run another means should have been chosen.

    Now that we’ve got all programs except antivirus running within the confines of the restricted user, we can think about protecting the user’s precious data from them (protection against apps installed as admin is hopeless).  One way to do this would to make user accounts hierarchical (note that I’m not talking about groups).  Let each user define any number of subaccounts, each of which can be granted access up to the level which the user master account has.  And let the user master account call CreateProcessAsUser into any subaccount.  Some sort of sticky bit capability would be helpful too, along with rights inheritance (e-mail program normally has no access to "My Documents", but if I invoke it using an editors’s Save to Mail Recipient feature then it can inherit the access of the editor).  Yeah, it would be complicated.  And some users would never bother.  But many would consider it worthwhile, as long as the effort to set it up is less than the effort to recover from identity theft.

  11. Dan says:

    An idea that occurred to me to make such sandboxing work with apps that can open and save files anywhere is to try and be tricky about it.

    Specifically, most apps that open and save files use the common dialogs to do so.  Any file the user specifically selects in such a dialog could be added to the sandbox.

    Of course there are plenty of problems with this seemingly simple solution:

    • An application could script itself to open the dialog, then set the text of the location text box to any file it wants, and click simulate clicking the open button to give itself access to any file it wants.  Ew.  Workaround would be to give the dialogs same treatment as UAC (THAT will go over well). Ew Ew.  And that would break dialogs which are extended with controls and code from the app anyway (since you can’t have this sandboxed code/controls working with the elevated dialog).
    • Some applications use file open dialogs to select directories instead of the more appropriate folder selection dialog.  Thus the permissions are granted on a particular file instead of the parent folder, which is what the app needs.  Other apps probably do even stranger things with the dialogs that wouldn’t work with the sandbox.

    • And if you extend it to the folder selection dialog, what folder(s) do you add to the sandbox permissions?  Do you add subfolders?  What if the user selects a drive root?

    Personally I think a more compatible alternative to sandboxing would be using a virtual machine.  Windows XP Mode, though I haven’t tried it yet (processor doesn’t support HW accel), looks like it’s got good desktop integration.  Only problem again is how to properly share documents between the VM and the host (I’m sure Windows XP Mode does SOMETHING for that but then again it’s not meant to act as a security barrier so it probably shares the whole host drive with the VM or something?).

  12. Jason says:

    There is sandboxie, but it looks a bit complicated.  It also doesn’t work on 64 bit windows because of increased kernel security.

  13. Aaron G says:

    @Ben: You’re kidding us, right?  User account hierarchy?  Rights inheritance?  "Sticky bit!?"  Sorry, but this idea of yours sounds like a classic case of solving a problem nobody has with a solution nobody wants based on 30 seconds of "wouldn’t it be nice if…" musing.

    UAC already does what I want, it prevents non-system programs from doing things that could mess up my system without at least warning me first.  I really could not care less if my word processor technically has access to my music folder.

  14. ERock says:

    @Aaron G: You’d probably care if it replaced the ID tags to something else.

    A sandbox is on the wishlist because of trust. It’s hard to trust that the application is going to do the right thing. As computers have gotten more powerful, there’s a lot of damage that can be quickly done out of malice or incompetence. It seems like, with UAC and even on a lower level with APIs, the trend has been moving away from trusting apps to do the right thing to acknowledging that sometimes they do the wrong thing.

    A lot of users simply don’t have the information network of peers to tell them that one application that does a particular thing does it more respectfully than another application that’s supposed to do the same thing. I still remember wincing when checking out what’s wrong with friends’ computers to find that RealPlayer was associated with all their media and completely trashing the system with startup agents and registry garbage.

    Yeah, sandboxing is hard, but, I personally think it’s a worthwhile endeavor. If the abstractions are too leaky, maybe we just need some new abstractions to adjust to the shift. :)

  15. Anonymous Coward says:

    Dan, I’ve been thinking along the same lines, but I’m not as pessimistic.

    Eric, that doesn’t help a single bit against the only problem that an operating system reinstall won’t fix: damaged user documents. Given the current state of technology it should be possible to safely run any arbitrary piece of software that runs in user mode. But we can’t because we’re afraid of losing data and settings.

  16. configurator says:

    I initially thought "Commenter Nick" was Commander Keen…

  17. Worf says:

    Wel, one way is to take advantage of the gobs of RAM and disk space, and virtualize. I run untrusted apps in a VM, the rollback the disk when I’m done.

    The problem with sandboxing can be best illustrated with a program most of us use – the humble compiler. Who has to read and write files all oover the place.

  18. Mark Grant says:

    "Linux could be said to have something like this with SELinux, and we’ve seen how much it’s being used and customized by end-users… (answer: it’ too arcane to be used by mere mortals.)"

    While I agree that SELinux is too arcane to be configured by mere mortals, it generally doesn’t need to be: I run SELinux on my CentOS box and it generally just works because some ‘super-human’ has generated a policy to cover most programs which are accessible from the Internet. And that requirement for centralised configuration isn’t to surprising as SELinux is designed to protect the computer from malicious users at least as much as it is to protect a user from malicious software.

    However, there’s also AppArmor, which is much easier to configure, with a simple text file specifying what access a program should have; it’s not as secure as SELinux (specifically, permissions are tied to the application path, not the inodes), but it does a decent job at protecting the user from malicious applications.

    Quite frankly, the lack of such control on Windows is one of the main reasons why I try to avoid using it anymore. I no longer trust random software not to interfere with my system even if it’s not officially classed as malware, particularly when I might later use the same system for ordering online by credit card or accessing online bank accounts.

  19. porter says:

    > I no longer trust random software not to interfere with my system

    I prefer not to install crap on my machine in the first place.

  20. Jeff Tyrrill says:

    @Eric Wilson:

    "Windows already has this feature.  Its called "not running as Administrator"."

    Not quite. Not running as Administrator sandboxes *users*. Sandboxing *applications* is a separate challenge. Such a feature would provide applications with far less than the user’s full privileges.

  21. Alexandre Grigoriev says:

    @Mark Grant,

    "(specifically, permissions are tied to the application path, not the inodes), but it does a decent job at protecting the user from malicious applications."

    Except from those applications that create links for themselves in trusted locations. You’re lucky nobody bothers exploiting those camel-sized holes. For Windows, hackers are too quick to exploit even needle-eye sized holes.

  22. Anonymous says:

    The SELinux people are trying, with a new thing called "sandbox -X":

  23. acq says:

    Mark Grant:

    particularly when I might later use the same system for ordering online by credit card or accessing online bank accounts.

    I use open and free software, but I claim you are not automatically more protected by using it. Look for how long nobody from developers noticed that encryption libraries in Debian (and autmoatically all distributions downstream) were seriously broken, so much that every server with public SSH with keys created in that period was de facto "open for everybody who would try" during almost two years. Most SSL certificates created on such systems were dangerous.

  24. Evan says:

    @Dan: "Some applications use file open dialogs to select directories instead of the more appropriate folder selection dialog."

    To be fair, if you’re thinking of the same dialog I am, the folder selection dialog is one of the crappiest pieces of UI that commonly shows up in Windows.

  25. Worf says:

    Unfortunately, you might not install crap, but your favorite trusted program might. Malware authors often buy advertising space on the big ad networks – and use vulnerabilities in IE to actually install their app. So that nice piece of ad-supported software might inadvertently install something. Even the big guys aren’t immune – those big trusted site may also host malware ads inadvertently.

    As for the Debian SSL issue, the keys weren’t bad, but they were significantly weaker and more guessable than they ought to be. It’s a concern, but not "all your SSL was in the clear". (Of course, the most dangerous person is someone who dabbles in crypto software without understanding it fully – a lot of oddities exist in crypto code because they work around key attacks and the like.)

    And let’s not forget an attack on CryptoAPI that lets people make fake Paypal certs (and all the browsers that use it)

  26. someone says:

    The redirection isn’t as much of a pain for users as the "Compatibility files" button UI experience is. There should be a saved search for locating all "compatibility files" on a volume.

  27. John C. Kirk says:

    I know this isn’t a .NET blog, but the .NET framework supports "Code Access Security" which is a form of sandboxing. I’m still trying to figure out how it all works, but I think it should be possible to say things like "My calculator can’t access the internet or modify any of my mp3 files".

  28. Ken Hagan says:

    Windows already has this feature. Choose "Run As…" and run as yourself but tick the checkbox marked "Protect me from viruses" (or whatever, I haven’t got a Windows box handy right now). The application will be prevented from writing just about everywhere, to stop it from dropping a Trojan on you.

    Of course, most applications just won’t work under such circumstances and, since MS have enough trouble persuading application authors not to require admin privileges, I really don’t think there’s much chance of persuading most authors to work in a sandbox.

  29. porter says:

    > My calculator can’t access the internet or modify any of my mp3 files

    I would be rather worried if my calculator had to use google to look up the result of a calculation.

  30. Ben Voigt [C++ MVP] says:

    <quote>I really could not care less if my word processor technically has access to my music folder.</quote>

    So run your word processor under your full user account, no need for any special trouble for it.

    But what about that stupid flash advertisement on MSN homepage trying to sell you car insurance?  It’s running code on your machine, as your user account.  Do you really trust Adobe to not perform any malicious tasks requested by that flash file?  (If so, go have a look at security holes in recent versions of Flash and Shockwave and rethink your answer.  If your answer is still yes, please disconnect your zombie-infested computer right now.)

  31. selinux = uac = suxxor says:

    SELinux is as useful as UAC. The first thing you turn OFF.

Comments are closed.

Skip to main content