AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |
Back to Blog
Fuse for macos core package4/30/2023 ![]() Thus, from the current version onwards, Fleischer simply distributed the kext without the source code. 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. 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. ![]() It is also possible that Apple didn't limit themselves to frowning. You could check that the kext was signed by him and notarised by Apple, and that nobody tampered with the code, but. 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. ![]() 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). There exist a gazillion reasons for that. 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.įor some reason, this became impractical in the current release cycle. 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). ![]() Benjamin Fleischer, the original developer, had a tough choice to make. 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 Comments
Read More
Leave a Reply. |