Add an explanation for why access to cfsprefsd is denied

This is denied by our general default policy, but since it generates
sandbox reports when sandbox logging is enabled it's helpful to have a
record of which denials are intentionally denied rather than yet to be
addressed.

This section will be fleshed out further as I have time to investigate
the other intentional denials.

Change-Id: Id3e0ac9a55df498e1fc92d3c3c597d753f083756
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4534381
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Auto-Submit: Mark Rowe <markrowe@chromium.org>
Commit-Queue: Robert Sesek <rsesek@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1144391}

sandbox/policy/mac/common.sb

@@ -342,3 +342,13 @@
       (syscall-number SYS_workq_kernreturn)
       (syscall-number SYS_workq_open)
 )))
+
+; Explicit denials. These are already covered by the blanket `(deny default)`,
+; but benefit from explanation as to why they're denied.
+(deny mach-lookup
+  ; CFPreferences falls back to in-process access to preference plists, known as
+  ; direct mode, when cfprefsd is inaccessible. This in-process access ensures
+  ; that our sandbox policy limits which preference domains can be accessed via
+  ; CFPreferences or NSUserDefaults.
+  (global-name "com.apple.cfprefsd.daemon")
+)