Adjust our process sandboxes based on seed user feedback as follows: (1) Silence spurious warnings about two XPC services we purposefully block: (global-name "com.apple.CoreServices.coreservicesd") (global-name "com.apple.DiskArbitration.diskarbitrationd") (2) Unblock an IOKit property needed for video playback feature detection: (iokit-property "compatible") (3) Allow file-read* access to "/Library/Fonts" in the network process to allow proper font serialization: (subpath "/Library/Fonts") (4) Allow access to the sysctl for "kern.osproductversion", which is needed by LaunchServices to detect some filesystem features. "kern.osproductversion"
<rdar://problem/50164879>
Created attachment 372656 [details] Patch
Committed r246702: <https://trac.webkit.org/changeset/246702>
<rdar://problem/52006224>
(In reply to Brent Fulgham from comment #0) > Adjust our process sandboxes based on seed user feedback as follows: > > (3) Allow file-read* access to "/Library/Fonts" in the network process to > allow proper font serialization: > (subpath "/Library/Fonts") What messages does the network process send or receive that include serialized font objects?
(In reply to mitz from comment #5) > (In reply to Brent Fulgham from comment #0) > > Adjust our process sandboxes based on seed user feedback as follows: > > > > (3) Allow file-read* access to "/Library/Fonts" in the network process to > > allow proper font serialization: > > (subpath "/Library/Fonts") > > What messages does the network process send or receive that include > serialized font objects? In this case, it was DidReceiveAuthenticationChallenge which wasn't actually serializing a font. However, the encoding code we use in all of our processes recognizes the possibility that it might be decoding (or encoding) a Font and instantiates a PlatformFont object that triggers access to the file I granted access to. That encoding is probably present for UIProcess <--> WebContent process communications, but it lives in NetworkProcess, too.
(In reply to Brent Fulgham from comment #6) > (In reply to mitz from comment #5) > > (In reply to Brent Fulgham from comment #0) > > > Adjust our process sandboxes based on seed user feedback as follows: > > > > > > (3) Allow file-read* access to "/Library/Fonts" in the network process to > > > allow proper font serialization: > > > (subpath "/Library/Fonts") > > > > What messages does the network process send or receive that include > > serialized font objects? > > In this case, it was DidReceiveAuthenticationChallenge which wasn't actually > serializing a font. However, the encoding code we use in all of our > processes recognizes the possibility that it might be decoding (or encoding) > a Font and instantiates a PlatformFont object that triggers access to the > file I granted access to. > > That encoding is probably present for UIProcess <--> WebContent process > communications, but it lives in NetworkProcess, too. So presumably this is happening when UIFont is initialized as a side effect of [object isKindOfClass:[PlatformFont class]] in typeFromObject(). This is a case where it’s better to use NSClassFromString() and avoid all costs (time, memory, and sandbox holes) of initializing the class. You could add something like static NSString const * PlatformFontClassName = @"NSColor"; and static NSString const * PlatformFontClassName = @"UIColor"; and so on alongside the declarations the top of the file and use those string constants for the class membership tests like I described.