2
Vote

Add FileSystem Watcher to encrypt new files

description

This is a feature I'm loath to try to implement, as I'm afraid of the potential downside in inserting something at the filesystem layer that will intercept all Writes. The Antivirus vendors had a helluva time trying to perform such things in Windows, such that they were disproportionately the cause of shell and/or OS instability and crashes. [I believe in the latest version(s) of Windows, they've implemented a shared function that removes the kernel hooks needed by each ISV, but it still gives me the willies.]
 
IF we were to try to implement such a feature, here's an incomplete list of requirements and processing workflow steps I believe we'd need to follow:
 
BAD
  • it would have to ignore all files created or modified by any other user except the Current User
  • it would have to wait to encrypt until after the file was closed, since all attempts to encrypt a file would require exclusive access
  • unfortunately, it would have to run at all times, and (because I wouldn't want to rely on its stability) it would have to process encryption requests immediately - I wouldn't want to rely on a work item queue of files to be encrypted
  • it would have to perform some very heavy-duty processing to determine whether the file should be encrypted or not (either based on some inference of folder path, or based on a hashtable of filetype - let alone the metadata or file contents proposals that are scary in their own right)
  • it would have to have some heuristics to ensure it didn't spend inordinate cycles chasing ephemeral files (i.e. those temporary files that are created and then very rapidly deleted)
  • it wouldn't really provide any value in preventing the creation of plaintext shreds on disk, since (unlike the EFS driver itself) it wouldn't create new files natively encrypted (cf. files created under an encrypted folder), but rather would only encrypt a copy of the plaintext file, and still leave behind the plaintext on disk on sectors allocated to the deleted plaintext file.
     
    GOOD
  • it could ignore all Read & Delete requests, focusing only on intercepting Write calls
  • it should skip all files that were created in encrypted folders (i.e. those files that will be encrypted regardless)
  • it could help with those files that are Moved not Copied, so that longstanding design flaw of NTFS could be beaten

comments

DaveMo wrote Jul 28, 2007 at 3:50 PM

It's not completely clear whether you are requesting a user-mode or kernel-mode solution. Since you describe FileSystemWatcher in your title, I think you are asking for a user mode solution. But a user mode solution (which I think is a reasonable first solution to the underlying issue) doesn't suffer most of the negative issues that you describe. The user-mode solution does not have any "kernel hooks" nor would there be any real chance of instability as you describe. I would not recommend a kernel-mode solution to solve the problem because of the stability risks and difficulty of implementation.

Using FileSystemWatcher, this is a relatively easy feature to add to EFSAssistant and one that I pushed for during development but was overruled due to the perceived risk of having a thread hanging around waiting for a file system event. IMHO, this kind of feature is low impact to the system and low risk.

I don't really understand your paragraph that starts with "heavy-duty processing". The straight-forward implementation is to run through the standard classification code since the rules for files that are just created should be the same as the rules for files that already exist. The current code takes way less then a second to process so I don't think there's any hidden issue we would need to address.

This is really only about 10 lines of code to implement but testing would take some cycles.

wrote Jul 28, 2007 at 3:51 PM

wrote Feb 13, 2013 at 6:48 PM