which actually was my case), macFUSE is a 'strange beast' for a simple reason: it is 'as open-source as Apple allows it', that is, there is a point where the core of the kernel extension that macFUSE has to install requires a valid signature and a notarisation by Apple - or else, you get all those suspicious warnings popping up all over the place, scaring users off (and - since it's a kernel extension - there might be certain configurations where macOS won't even install an unsigned/unnotarized kext anyway). I would trust that too from a security perspective though not necessarily as much from a stability perspective, though it’s mostly fine if you only intend on reading files not writing.įor the benefit of those in the future getting redirected here by Google (or Bing. I would assume that the programs you list, trevorit and cryptomator use already existing FUSE packages though, like ext4fuse or whatever the package is called. Whether file system support layers on top of it are trustworthy is a case by case basis, but as a result of the FUSE model, if they are not, their harm is at the very least limited to the file system they add support for (unless they find a way to exploit the macFUSE kext itself). Anything that runs in kernel space can bring down the whole system if it’s buggy or potentially allow arbitrary code execution with kernel privileges if exploitable.īut again, I do trust macFUSE itself.
MacFUSE itself is also a kernel extension and while I trust macFUSE itself, a kernel extension will increase the attack surface and the system crash likelihood - that’s basically inevitable. A file system support package would still be able to snoop on the files it is responsible for, but it wouldn’t be able to snoop on files from other file systems. MacFUSE itself is still open source, and the principle behind FUSE is to have file system support in user space which improves security in the sense that the file system support won’t have kernel access.
0 kommentar(er)
