Bug 199119 – Adjust sandboxes based on seed feedback

• Component: WebKit Misc.
• Status: RESOLVED FIXED

[Brent Fulgham]

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"

[Brent Fulgham]

<rdar://problem/50164879>

[Brent Fulgham]

Created attachment 372656 [details]
Patch

[Brent Fulgham]

Committed r246702: <https://trac.webkit.org/changeset/246702>

[Radar WebKit Bug Importer]

<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?

[Brent Fulgham]

(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.