Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

hashim9372

macrumors newbie
Original poster
Aug 9, 2021
4
2
Hi there, apologies if this post is in the wrong forum - I'm new here.

I've recently downloaded Cryptomator (and in the past, Tresorit) both of which require (or in the very least recommend) macFUSE to be downloaded in order for files from different operating systems to be read on Mac.

I'm not too tech savvy, so I apologise if that explanation is wrong - but before I go about using Cryptomator to encrypt my OneDrive, I just wanted to ask if its a safe application to use? Of course, now that its closed source I can't expect you to make any promises, but has there been a history of the software collecting sensitive data, acting as malware and so on, especially in your own personal usage? Or has it always been trustworthy?

Thanks.
 
Depends on the definition of safe.

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. 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 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. 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.

But again, I do trust macFUSE itself. 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).
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. 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.
 
  • Like
Reactions: Big Ron
Depends on the definition of safe.

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. 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 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. 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.

But again, I do trust macFUSE itself. 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).
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. 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.
Hi there - I can't thank you enough for the thorough yet understandable response.

I'm not sure whether you're familiar with Cryptomator, but it works by accessing a particular cloud storage's file system and creating an encrypted vault within it that isn't accessible unless opened with Cryptomator, either via its desktop or mobile apps.

So in terms of functionality, I'd be using Cryptomator to view files, which themselves are stored on a third party cloud storage operators servers, but encrypted on device.

Does an activity like this sound like something which may exacerbate any inherent security flaws which arise from the use of FUSE?

Thanks.
 
  • Like
Reactions: Big Ron
Hi there - I can't thank you enough for the thorough yet understandable response.

I'm not sure whether you're familiar with Cryptomator, but it works by accessing a particular cloud storage's file system and creating an encrypted vault within it that isn't accessible unless opened with Cryptomator, either via its desktop or mobile apps.

So in terms of functionality, I'd be using Cryptomator to view files, which themselves are stored on a third party cloud storage operators servers, but encrypted on device.

Does an activity like this sound like something which may exacerbate any inherent security flaws which arise from the use of FUSE?

Thanks.
As long as you trust the Cryptomator software itself and don't believe it's storing backdoors and whatnot into your data then there's nothing "extra" about FUSE that would worry me there
 
Thank you! I'm pleased to say that they are open source, and whilst I'm nowhere near qualified enough to read the code provided on GitHub, I have faith in those who are better equipped than me to keep me safe!

And indeed, pancakes really is a lovely word.
 
  • Like
Reactions: casperes1996
Flapjacks ain't bad either pancakes_1f95e.png

Lou
 
On the topic of MacFUSE, I find it strange that the current release of its useful companion SSHFS is over 7 years old.

Screenshot 2021-08-12 at 12.33.34.png

That and the news stories a couple of years ago about MacFUSE oscillating between open- and closed- source kinda put me off this stuff in general (though I don't remember actually having any substantive complaints about the software).
 
For the benefit of those in the future getting redirected here by Google (or Bing... 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). Benjamin Fleischer, the original developer, had a tough choice to make. Obviously he wasn't going to keep his Apple developer digital signature around to be used by anyone — which would get blocked by Apple in no time anyway (and not even entitle him to a refund). The first alternative to that (and I believe that was what he did in the past releases) would be to do both: release the open-source code of the kext (you can still grab it) but also bundle a signed/notarised binary version for those who trust him, to avoid macOS to trigger DEFCON 5.

For some reason, this became impractical in the current release cycle. There exist a gazillion reasons for that. Maybe Apple frowned upon a 'parallel' release of open-source code and a code-signed/notarised kext that allegedly was compiled from that source code — but the truth is that nobody can know that (possibly not even Apple, if they wished to check on their own). At the end of the day, if you used Fleischer's compiled/signed/notarised binary, you'd have to trust him that he had, in fact, compiled it from the open source code he also provided; you couldn't know for sure. You could check that the kext was signed by him and notarised by Apple, and that nobody tampered with the code, but... what code? You cannot possibly know.

It is also possible that Apple didn't limit themselves to frowning. They might have alerted Fleischer and told him that his distribution model of a kernel extension — signed and notarised by Apple — was 'not acceptable', and either he changed his approach, or Apple would revoke his current developer license and signature. Again, I'm only speculating what Apple might told Fleischer or not, but I can imagine such a scenario to be plausible, if not possible.

Thus, from the current version onwards, Fleischer simply distributed the kext without the source code. If it's a question of trust anyway, just distributing the kext in binary format as freeware is perfectly legitimate — freeware is still popular without open-source code, after all; one thing does not necessarily imply the other, and there is lots of perfectly safe freeware around :)

But of course there is nobody (except perhaps Apple) that can demand that you trust person X or Y, 'just because everybody else does'. Fleischer has a good reputation — after all, he's still behind the codebase — and macFUSE is still being maintained (while SSHFS probably doesn't really need an update — which it hadn't have since 2014! — simply because, well, the SSH protocol hasn't really changed since then... and it might only change in a decade or two, when it will need to deal with post-quantum encryption or whatever we'll get in 2040 :p ). It is trusted by very-security-conscious companies such as Keybase — who also bases their code on macFUSE (albeit on an older version, forked by them, exactly because of the issue of signing & notarising bundled software in the same installer).

In short: there is no reason to mistrust macFUSE's closed-source, freeware kernel extension. Nevertheless, it's up to you to evaluate the amount of trust you're willing to put on any software installed on your system. Apple will only guarantee — and even that just to a degree — what you've installed from their App Store; apps 'in the wild' — even those notarised by Apple! — are a different story. There is always a certain degree of risk; as the old saying goes, any computer connected (directly or indirectly!) to the Internet is subject to some risk. We nevertheless use them every day...
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.