Summary: | Adjust sandboxes based on seed feedback | ||||||
---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Brent Fulgham <bfulgham> | ||||
Component: | WebKit Misc. | Assignee: | Brent Fulgham <bfulgham> | ||||
Status: | RESOLVED FIXED | ||||||
Severity: | Normal | CC: | bfulgham, eric.carlson, ggaren, mitz, pvollan, webkit-bug-importer | ||||
Priority: | P2 | Keywords: | InRadar | ||||
Version: | Safari 10 | ||||||
Hardware: | Unspecified | ||||||
OS: | Unspecified | ||||||
See Also: | https://bugs.webkit.org/show_bug.cgi?id=199140 | ||||||
Attachments: |
|
Description
Brent Fulgham
2019-06-21 15:09:03 PDT
Created attachment 372656 [details]
Patch
Committed r246702: <https://trac.webkit.org/changeset/246702> (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. |