Is this project suitable to build an application based restricted filesystem? *Windows OS*

[cpainchaud]

Hi!

I often manipulate sensitive data and I would like to ensure that only a specific program (identified by its path and/or digital signature) has access specific folders so any other program trying to access it would be denied. Even Windows Explorer should be denied or even the system.

As a developer I often have to use more or less secure way to store credentials for the sake of automation or convenience (like .conf .ini files or rely on my various terminal programs encryption to ensure they do it right).

Any virus or remote control program could just copy all the files are any time but now if I can control which processes can access my files.... All the data would be stored in a big file/block which would be encrypted ofc. My intent is very much like mounting a TrueCrypt volume but with a process based identification to ensure nothing can steal the data.

I was wondering if :

• this project would be suitable for my needs (I read it can provide the process id from which I think I can trace back to the exe and its digital signature for example)
• I am not reinventing the wheel (honestly it should be part of the OS in my opinion, each application needs a secure vault accessible only from a vendor's signed executable, it sounds like a basic for me but I digged the forums without finding anything)

Thank you for reading so far!

[billziss-gh]

I often manipulate sensitive data and I would like to ensure that only a specific program (identified by its path and/or digital signature) has access specific folders so any other program trying to access it would be denied. Even Windows Explorer should be denied or even the system.

What you want is possible, but there are caveats. You need to understand the caveats and decide whether the implied security is enough for your needs.

Windows file system security is based on controlling access when files are being opened. This means that whenever the CreateFile (or equivalent) API is used, the file system applies access control. If the call succeeds, then the returned HANDLE does not usually have any additional access controls imposed on it (other than ensuring that the HANDLE is only used for the accesses given when the file was opened). The obvious caveat here is that if the HANDLE is somehow "passed" (inherited, duplicated, etc.) to another process, then that other process will have access through the HANDLE.

Additionally system components may have unfettered access to files:

• The OS has direct access to any opened HANDLE since it is the conduit between an application and a file system driver.
• Filter drivers may have direct accesses to any opened HANDLE since they also sit somewhere between an application and a file system driver.

These system components live in kernel space and are therefore "safe". However some of them may choose to "ship" your HANDLE to a user mode process (e.g. MsMpEng.exe -- note that this is speculation on my part as I do not really know how Windows Defender works).

Beyond direct access to any HANDLE that an application itself opens, the OS (and some filters) may sometimes try to open files themselves. These are easy to identify and a file system driver can deny access, although this may result in degraded performance or break the file system (e.g. I expect that if a file system denies root directory access to the operating system, the file system will likely not get mounted).

With these caveats (and perhaps more) in mind, the answer is that: yes, you can do that in WinFsp. The native WinFsp API provides access to the ID of the process that is opening files (FspFileSystemOperationProcessId). Your file system can then decide to allow or deny requests based on this process ID.

[cpainchaud]

Thank you very much for taking the time to answer!

[Dwedit]

If you want an filesystem only accessible by one process, you can detour the NTDLL functions that have to do with files (such as NtCreateFile). Because everything file-related ultimately calls NTDLL functions, you completely control how the app sees the filesystem.

[billziss-gh]

A determined application could still work around this by e.g. directly issuing the system call for NtCreateFile. (Note that system call number change from release to release.)

[Dwedit]

Not gonna happen. Using system call numbers ties your application to an overly specific version of Windows 10/11, and it will break on the next Windows Update.

Normal applications will just call the Win32 APIs because that's what fopen will do.

Only a program that's going way out of its way to be anti-hook would resort to directly calling system call numbers (and would probably combine that with anti-debug nonsense where the code doesn't actually exist in memory until right before it's executed). Even then, a kernel-mode filter driver would still override the application.

[billziss-gh]

The point is that detouring NTDLL functions is not a bulletproof solution for providing security.

I agree that the only good solution is via a kernel-model driver.