File system audit

[Takhir Bedertdinov]

Thank you for the great job, Bill Zissimopoulo!

Some of our customers would like to use Windows Audit to track access to storage files. CBFS/CbfsConnect drives have not access to SACL information in file properties, and Callback Technologies has not plans to implement that. WinFsp displays and works with Audit page properly (Properties->Advanced->Audit). I double checked that SACL information present in dirs/files SD on memfs drive after that. Unfortunatelly, when we try to check system audit events (directly in Event viewer or using tools like "PA File Sight"), we can see events from native NTFS drive, but not from WinFsp memfs drive. To be sure, I also changed FS name to NTFS, but this did not help. Can you clarify this feature support? May be we do something wrong?

One more question (sorry, 2 questions in one request ;) ). CBFS supports drive mount as a network share, such drive is visible in "net view" as a normal SMB shares. Do you plan to implement this mount in future, or the only way is to use CLI/API for sharing?

BTW I tested Eldos CBFS, Callback Technologies CBFS Connect, WinFsp and Dokany on Server 2019 Insiders Preview 17692, and up to now all worked correct (except Audit). But we expect that legacy drivers like CBFS may be prohibited in this version later. And this is another reason of our interest to WinFsp ;).

Thanks, Takhir

[bill...@navimatics.com]

Takhir, my apologies for the late response. For some reason I did not receive an email notification for your post (although I did receive your request to join) so I am only now seeing your post on the website.

Unfortunately I do not have a clear answer for you regarding SACL support by WinFsp. In general WinFsp should store SACL's correctly, but the SACL code paths have not been specifically tested. If you need good SACL support in WinFsp, please open a GitHub issue and document that need.

Regarding your second question. Yes, WinFsp supports mounting a file system as a network drive. For example, in memfs you need to use the -u \server\share option. Please note that a "network drive" is not the same as a "network share".

If you instead mean exposing a WinFsp drive as a network share, this is also possible. You must start the file system as a "disk" drive (i.e. no -u flag on memfs) under the SYSTEM account. (Starting the file system under the SYSTEM account ensures that the created drive is visible to all users and the NetShareAdd API). You must then use the NetShareAdd API to expose the drive as a file share.

Bill

[Takhir Bedertdinov]

Bill, I can confirm that WinFsp works correctly with security attributes, SACL comes to SD as expected. Problem is that Windows don't catch file access events on the WinFsp virtual drive. I tested 2 directjries, one on the regular NTFS drive (C:) and another on WinFsp memfs drive (T:). Both dirs have similar SACL in SD, File system Audit enabled. But Windows logs has access events only from C: drive. May be system not recognizes memfs as 'native'? Or may be this is because of WinFsp driver position in FS drivers stack (above audit tracker layer)?

And about 'network share'. Is it possible to share drive without exposing it as a local drive? CBFS allows creating a hidden drive (similar to WinFsp 'network drive') and using of such drive for 'network sharing'. This is not only about 25 letters limitation, but some customers prefer not to show data mounted even to folder. Was sharing of such hidden 'network drive' tested (for example with NetShareAdd API)?

Thanks, Takhir

[Bill Zissimopoulos]

Takhir, hi. My comments inline.

On 7/19/18, 10:21 AM, win...@googlegroups.com on behalf of Takhir Bedertdinov wrote:

Bill, I can confirm that WinFsp works correctly with security attributes, SACL comes to SD as expected. Problem is that Windows don't catch file access events on the WinFsp virtual drive. I tested 2 directjries, one on the regular NTFS drive (C:) and another on WinFsp memfs drive (T:). Both dirs have similar SACL in SD, File system Audit enabled. But Windows logs has access events only from C: drive. May be system not recognizes memfs as 'native'? Or may be this is because of WinFsp driver position in FS drivers stack (above audit tracker layer)?

I did a bit of research on this. WinFsp does not currently call any of the kernel auditing DDI’s such as SeAuditingFileEvents or SeOpenObjectAuditAlarm. So it preserves SACL’s but does not do anything with them.

Please consider adding a feature request on GitHub if you need this functionality.

And about 'network share'. Is it possible to share drive without exposing it as a local drive? CBFS allows creating a hidden drive (similar to WinFsp 'network drive') and using of such drive for 'network sharing'. This is not only about 25 letters limitation, but some customers prefer not to show data mounted even to folder. Was sharing of such hidden 'network drive' tested (for example with NetShareAdd API)?

In order to make sure that we are talking about the same things here let me discuss a few different terms:

• “Disk” file system: a file system that is backed by a (real or virtual) disk drive. WinFsp supports such file systems. The file system will be accessible as a device with a name such as `\Device\Volume{GUID}` in the NT namespace. It may or may not have a drive letter (X:) assigned to it.
• “Network” file system: a file system that is accessible only through the MUP (Multiple UNC Provider — a Windows kernel component) using a syntax `\??\UNC\{Server}\{Share}` in the NT namespace (or \\{Server}\{Share} in the Win32 namespace). WinFsp also supports such a file system and they also may or may not have a drive letter (X:) assigned to it.
  • It should be noted that a “Network” file system is NOT a network share, although Windows uses the MUP as a component in its general implementation of file networking. A “Network” file system will not be exposed by Windows as a shared drive or directory.
• “Network” share: Windows makes a drive/directory available to the network. This is accomplished by running file server software on the Windows computer that contains the drive/directory. Another Windows computer connects to the file share and exposes it as a file system attached to the computer; this is accomplished by running file client software on the computer. (The file client software runs in fact as a “network” file system and is accessible through the MUP.) Network shares are supported by WinFsp, but note that only disk file systems (or their directories) can be exposed as network shares (this is a Windows limitation).

Hopefully it is now more clear that “network” file system is not the same as “network” share.

It is possible to create a “hidden” disk or network file system. In WinFsp you need to call the FspSetMountPoint to mount it as a drive or directory. If you do not call this API the file system will exist, but will remain “hidden”.

This means that the file system would be accessible from Win32 as:

\\?\GLOBALROOT\Device\Volume{GUID}

For a “network” file system with a “VolumePrefix” of “\Server\Share” it would also be accessible as:

\\Server\Share

Hope this makes sense.

Bill

[Takhir Bedertdinov]

Thanks, Bill.

> I did a bit of research on this. WinFsp does not currently call any of the kernel auditing DDI’s such as SeAuditingFileEvents or SeOpenObjectAuditAlarm. So it preserves SACL’s but does not do anything with them.

> Please consider adding a feature request on GitHub if you need this functionality.

May be I will add this after deeper testing. We need to clarify situation with best driver for Server 2019 first ;).

Thanks again,

Takhir