fskit-sandbox.md

Here are Apple-provided sources you can point at that show FSKit file system extensions are entitlement-gated and live in the "extension / system extension" world (not "just load a plugin"):

• FSKit overview (Apple docs) --- explicitly says you deliver an FSKit module as an app extension that runs in user space. 

• FSKit Module entitlement (Apple docs) --- com.apple.developer.fskit.fsmodule is the entitlement that indicates an extension provides an FSKit filesystem (i.e., without it you're not "an FSKit filesystem extension" in the eyes of the OS).

• System Extension install entitlement (Apple docs) --- com.apple.developer.system-extension.install is the entitlement that allows a host app to activate/deactivate system extensions (the general mechanism used to get these kinds of extensions loaded/managed on macOS). 

• WWDC statement about extension sandboxing --- Apple describes extension code being isolated into its own daemon process that's sandboxed (this example is a camera extension talk, but it's an Apple primary source explicitly describing the sandboxing model for extension daemons).

If what you specifically want is the "FSKit modules are system extensions" sentence in Apple docs (as opposed to "app extension"), that wording is a bit inconsistent across Apple pages/snippets, but the entitlement + "delivered as an app extension" combo above is already a strong, citable chain for "you need entitlements / you don't get loaded unless you're in the blessed extension pipeline."

---

Here are Apple-provided sources you can point at that show FSKit file system extensions are entitlement-gated and live in the "extension / system extension" world (not "just load a plugin"):

• FSKit overview (Apple docs) --- explicitly says you deliver an FSKit module as an app extension that runs in user space. 

• FSKit Module entitlement (Apple docs) --- com.apple.developer.fskit.fsmodule is the entitlement that indicates an extension provides an FSKit filesystem (i.e., without it you're not "an FSKit filesystem extension" in the eyes of the OS).

• System Extension install entitlement (Apple docs) --- com.apple.developer.system-extension.install is the entitlement that allows a host app to activate/deactivate system extensions (the general mechanism used to get these kinds of extensions loaded/managed on macOS). 

• WWDC statement about extension sandboxing --- Apple describes extension code being isolated into its own daemon process that's sandboxed (this example is a camera extension talk, bShort answer: yes --- all FSKit filesystem extensions are sandboxed, including during development. There is no "unsandboxed dev mode" for FSKit.

Here's the precise picture.

---

Are FSKit extensions sandboxed?

Yes, always.

An FSKit filesystem is delivered as an extension that runs in its own user-space process, under Seatbelt sandboxing, and is entitlement-gated. That's true whether you're:

• running from Xcode

• using a Development signing identity

• loading on your own machine

• shipping to users

There is no API or boot arg equivalent to "just dlopen my FS and poke the kernel".

This is a hard architectural boundary, not a policy choice.

---

**What **

kind

** of sandbox is it?**

Think of an FSKit module as:

"a tightly sandboxed, entitlement-based system extension whose only privileged surface is the filesystem protocol it implements."

Key points:

• Runs in user space, not the kernel

• Runs in a dedicated daemon process

• Uses XPC to talk to the system's filesystem stack

• Governed by:

  • the standard macOS app sandbox

  • FSKit-specific entitlements

  • no implicit filesystem access outside its mount

---

What does an FSKit extension have access to?

**✅ What it **

can

** access**

• Its own container

  • ~/Library/Containers//

• Memory, CPU, threads like any user-space process

• The backing store you explicitly open

  • disk image

  • block device

  • network connection

  • file descriptor passed in by the system

• The mounted filesystem namespace

  • but only through FSKit APIs, not raw POSIX wandering

• Limited I/O

  • network, if you request the entitlement

  • IPC via XPC

• Logging, debugging, crash reports

  • including via Console.app and unified logging

**❌ What it **

cannot

** access**

• Arbitrary parts of the host filesystem

• /Users, /System, /private, etc. unless explicitly granted (they aren't)

• Kernel memory or kernel APIs

• Other processes' memory

• Raw block devices without system mediation

• "Just read random files because I'm a filesystem"

Even though it implements a filesystem, it does not escape the sandbox.

---

Important subtlety: "filesystem authority" ≠ "process authority"

This is the part people often get wrong.

Your FSKit extension is authoritative only over the filesystem it exposes.

That authority is logical, not ambient.

So:

• You can decide how /Volumes/MyFS/foo.txt behaves

• But you cannot open /etc/passwd just because you're a filesystem

• You don't inherit the caller's permissions

• You don't get "kernel-adjacent" privileges

The system acts as a policy firewall between:

• VFS ↔ your FSKit code

• user processes ↔ your extension

---

During development specifically

Nothing is loosened, except:

• Code signing is Development instead of Distribution

• You can attach a debugger

• You can reinstall / reload more easily

But:

• Sandbox stays on

• Entitlement checks stay on

• Extension isolation stays on

• User approval (where applicable) still applies

If your FSKit code works in dev, it works in prod because the environment is fundamentally the same.

---

Mental model (useful one)

FSKit is deliberately designed so that:

"Implementing a filesystem is treated as less dangerous than running arbitrary kernel code --- but more dangerous than a normal app."

So Apple gives you:

• a narrow, audited interface

• a strong sandbox

• no escape hatches

• no legacy kext-style trust

That's why FSKit exists at all.

---

If you want, I can:

• map FSKit entitlements → concrete capabilities

• compare FSKit vs old KEXT filesystems in terms of privilege

• explain what actually enforces the sandbox boundary (Seatbelt + launchd + systemextensiond)

Just say the word.ut it's an Apple primary source explicitly describing the sandboxing model for extension daemons).

If what you specifically want is the "FSKit modules are system extensions" sentence in Apple docs (as opposed to "app extension"), that wording is a bit inconsistent across Apple pages/snippets, but the entitlement + "delivered as an app extension" combo above is already a strong, citable chain for "you need entitlements / you don't get loaded unless you're in the blessed extension pipeline."