The idea goes like this:
First, we need a monitor of all filesystem activity. Something than can intercept all such requests, and then decide to block them or let them happen. I know that this is possible, because that's how resident AV-software can work.
Then, the user can select a directory, and choose how "internal" and how "external" access *from apps inside that directory* is handled. Imagine a directory-structure like this:
Code: Select all
C:\
D:\
MYDOCS\
MYAPPS\
FIREFOX\
NOTEPAD2\
TOTALCOMMANDER\
More specifically, we are only concerned with write-access. Read access is allowed always. There is a little problem with this, which i will get into at the end of this proposal.
Lets start with the easier part - external access. We get to choose to either allow all external access or block all external access. Thus, everything inside MYAPPS may either access things outside of MYAPPS, or may not. Additionally, we can define exceptions for certain subdirs inside MYAPPS for which the opposite will be true. For example, we can say that things in MYAPPS may not access things outside of MYAPPS, but can make an exception for the subdir TOTALCOMMANDER, because totalcommander is a filemanager which we'd want to give full access.
Thats already everything there is to external access. You simply select a directory that contains app-subdirs, and then say which may write outside of that maindirectory (like a sandbox).
Policing internal access (so, which things in MYAPPS an app inside MYAPPS may modify) works a bit different, and is the key feature of my proposal. We can say if internal access should be restricted or unrestricted. If internal access is restricted, then FIREFOX/ may only write to FIREFOX/, NOTEPAD2/ may only write to NOTEPAD2/, and WINCOMMANDER/ may only write to WINCOMMANDER/. Here again we can define exceptions, by for example saying, that TOTALCOMMANDER/ may internally write unrestricted.
By combining those simple features of internal access and external access, plus exceptions, you can police all your applications properly, by setting just a handful of rules for the superdirectory. And it is "set it and forget it" - you don't need to define new rules, when you add more applications, unless they require an exception. The making of exceptions can be made even easier, by letting the user tell the monitor, that it should ask the user if any app tries to do something that the current rules do not allow. This also can be used to "monitor" new applications for a while, to see how they behave (thus, you can also use this model to create sandboxes for evaluating new software).
This model is a strongly slimmed down version of a larger concept of mine. My original concept required a specialized OS and filesystem to do much more - like i.e. policing network connections the same way, builtin live lookup of portable dynamic libraries, associations, and a few more things. But since such an OS doesn't exist yet, i came up with the "monitor" version that could implement a subset of these features on top of nowadays OSes.
---
Problems:
1.
No writeaccess - fine, but what to do about executions? Can a restricted application execute a system app that formats a partition? For the model to work, such "calls" would need to be handled in the context of the caller. That is: If a file in MYAPPS calls "format E:", then the write access of the format-application would need to be interpreted as originating from MYAPPS - and thus be forbidden. Another approach - the one which my original concept used - would be that for external access, you do not define which OUTBOUND access is allowed, but instead which INBOUND access is allowed (so, you define if access from outside INTO the directory is allowed). While this is more sane (its mutual consent: One agrees my making the request - another one agrees by allowing it), it requires that everything on the computer defines if it allows outside write access - which is okay if the OS is designed for this from the ground-up anyways, but not okay if we try to "patch" a system that isn't designed for this.
2.
Existing applications aren't designed for this. They spread their crap all across the hdd and into the system, and then want write access to this stuff (i.e. registry). The only way to keep the model compatible with such applications is virtualization: Any disallowed write-access would need to be virtualized ala JPE/ThinApp. So, for this model to work in practice, it would need to be part of an application-virtualizer.
3.
Not portable - or at least not unless we have admin-rights. Since WE are supplying the watchdog (instead of it already being available on the system), we need the rights to execute a system driver (kernelland).