On the fly VMs: Viable security model for downloaded apps?

I’ve been thinking… always quite dangerous I know…

I woke up early this morning and couldn’t get back to sleep and for some unknown reason I started thinking about downloaded applications and how to prevent trojans getting a hold. Then it came to me, why let the application have real access to the system, especially the filesystem?

I started wondering how feasible it would be to modify the operating system to create on the fly a virtual machine which is a clone of itself within which an untrusted application is run. This VM would not have any real write access to the filesystem but instead would have a copy-on-write shadow copy of the real one. For performance reasons it would have to have pretty transparent access to the graphics sub-system but this shouldn’t be too high a security risk. Once the application had terminated the filesystem write operations could then be vetted and a risk assessment and “reputation” for the application could be determined before actually making the changes to the real data on the disk.

Later on the application could either be manually unrestricted or, if it’s “reputation” was above a certain threshold, unrestricted manually.

Anyway, it was just a thought.

[Edit] More thoughts added as a comment.

4 thoughts on “On the fly VMs: Viable security model for downloaded apps?

  1. Actually, I’ve given this more thought. Why restrict this to only downloaded executables? Why not make the levels of “reputation” mean something and do something useful?

    For example, let’s use Windows as an example system for the restrictions:

    (-3) Lowest reputation: Program has own shadow copy of filesystem, global registry and user registry. Only files within user’s data space written back once application exits.

    (-2) Medium reputation: Program has per application shadow copy of filesystem, global registry but has write-back access to user registry and filespace.

    (-1) Resonable reputation: Program has user-level shadow copy of system filesystem and global registry, direct access to user filespace and write-back access to user registry.

    (0) Normal reputation: Program has user-level shadow copy of system filesystem and global registry but direct access to user’s filesystem and user registry.

    Above these levels would be system level reputations giving varying access to system files and devices etc.

    Users could be given a base reputation, then the executables they ran would have a consummate lower level of reputation as well. e.g. giving a user a reputation of -3 would mean that all applications they ran would have a reputation three lower than they would otherwise have.

  2. One could argue that this isn’t much different from the sandboxing models that ActiveX and Java use. You’re now at the mercy of whoever writes your VM software as well as your OS vendor’s security. I’ll give you the words of Theo de Raadt on the subject: http://kerneltrap.org/OpenBSD/Virtualization_Security

    Next, you seem to have reinvented UAC and/or the protected mode that IE on Vista/7 use.

    The problem as always is the application vendors. The ones that are still stuck in the win9x mindset, a decade after that went obsolete. They will find ways to make things break when run in a locked down environment, so you end up having to open yourself up again to get things done.

    • It’s not quite UAC or a normal sandbox. It’s more a virtualisation of the whole filesystem underneath the application *AND* the DLLs that it’s using.

      So, at the system level the system DLLs that the application is running have no idea that they’re operating of a virtual copy of the files that they’re trying to manipulate. In fact, there should be no way that they could find out.

      In the most restricted level the system would be creating a file containing a journal or difference file which would then be used the next time the application ran so that no modifications to the real filesystem would take place (other than the storage of the difference file).

    • P.S. In this scenario, even if the process gained full administrative privileges it would *STILL* only be writing to its own private virtual view of the filesystem etc.. i.e. no other processes would see any change.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.