Inquiry Regarding File Scan Permissions for Anti-Malware Feature Implementation

When running the process as a user, it fails to scan some files due to lack of read permissions. Conversely, when running the process as root, it cannot scan files in the Home subfolders due to privacy restrictions. Could you please advise on the best approach to achieve this configuration?

The "Full Disk Access" authorization exists to facilitate the sort of thing you're describing. It disable the user privacy protection that's blocking access above. You can find the Full Disk Access setting in "System Settings > Privacy & Security > Privacy".

Also, on a side note, what you're describing here is no longer the correct approach:

To achieve this, we added a plist file in the /Library/LaunchDaemons directory

LaunchDaemon's should remain embedded inside their parent app bundle and managed through "SMAppService".

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

The "Full Disk Access" authorization exists to facilitate the sort of thing you're describing. It disable the user privacy protection that's blocking access above. You can find the Full Disk Access setting in "System Settings > Privacy & Security > Privacy".

If I configure a LaunchDaemon using “SMAppService”, will the LaunchDaemon also share the “Full Disk Access” permission of the main app?

LaunchDaemon's should remain embedded inside their parent app bundle and managed through "SMAppService".

"SMAppService" is supported only on macOS 13 and later. If I configure a LaunchDaemon using a plist on earlier macOS versions, can it still use the “Full Disk Access” permission?

The "Full Disk Access" authorization exists to facilitate the sort of thing you're describing. It disable the user privacy protection that's blocking access above. You can find the Full Disk Access setting in "System Settings > Privacy & Security > Privacy".

If I configure a LaunchDaemon using “SMAppService”, will the LaunchDaemon also share the “Full Disk Access” permission of the main app?

Two answers to that:

1. Yes. Part of the reason this API exists is that keeping the all of the app components inside the app bundle makes it easier to ensure that TCC permission can be correctly inherited, including FDA.

2. Qualified "but". Bugs are always possible, particularly with components that are executing outside the "standard" execution flow (like a LaunchDaemon running as root). If your app relies on FDA, then you should also consider how you'll handle access failures in a clean/graceful way. Keep in mind that there are many reasons access can fail (for example, Endpoint Security extensions or system external permission systems) beyond FDA.

"SMAppService" is supported only on macOS 13 and later. If I configure a LaunchDaemon using a plist on earlier macOS versions, can it still use the “Full Disk Access” permission?

First off, I would think carefully about exactly what system range you're willing/able to support, particularly in terms of when your product will actually ship. Choosing to support a broader system range can easily create a situation where older systems generate relatively little revenue (because older systems tend to install/buy far less software) and high support cost (because of the extra testing cost and difficulty of investigating problems on older systems).

Having said that, yes, you can grant FDA to a LaunchDaemon. My big recommendation here is that you package your daemon inside an app bundle instead of installing it as a "bare" executable. Putting that in more concrete terms, instead of having your launchd plist point to:

<path>/myexecutable

Put that executable inside an app bundle and have your launchd plist point to:

<path>/MySecurityApp.app/Contents/MacOS/myexecutable

Launchd itself won't care and never has*, as your plist simply points to slightly longer path (the executable inside the app bundle). However, using an app bundle means that you "fit" within the expectations the "rest" of the system has, minimizing the possibility of failure.

*Making sure this point is clear, launchd has NEVER required that executables follow any particular pattern or structure. Most of our daemon's do use "bare" executables, but that's PURELY because of how "we happened to do it" and not because bundling executables has (or ever had) any real downside.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware