Depending on what attack scenario you envision, disabling unixfs is not enough.
If you want to avoid actually executed malware from accessing the UNIX fs directly, you are out of luck as the malware could just do systemcalls itself (int 0x80 on x86 for instance).
Yup, I'm aware of that -- if I'm going to run potentially malicious code I'll run it in a VM. (: My concern is more for cases like otherwise well-behaved programs that passively report to some remote server what they see, such as when listing folders via the shell interface -- ideally I'd like to limit what they see without the overhead of setting up a full VM.
Might it be worth adding a note about both unixfs and the syscall issue to the documentation? The only reference I found to host filesystem access is under section 4.1.4 "Drive Settings". Maybe add some text like:
""" Wine also provides a Windows share which allows modern applications to access native Unix paths even without a drive mapping. This will show up as "/" in file dialogs.
Note that removing the default "z:" drive mapping will NOT prevent Windows applications from reading your entire filesystem! In addition to the Windows share, malicious programs could detect that they are running under Wine and execute native Linux system calls to get around any restrictions imposed by Wine. Consider running programs you don't trust in a virtual machine instead. """
Just a thought,
--Andrew Church achurch@achurch.org http://achurch.org/