Initially, preference services were blocked by using CFPrefs direct mode. However, it is possible to keep denying preference services without using direct mode by issuing temporary extensions to preference services. On startup of the WebContent process, consume these extensions, then perform a dummy preference request to map preferences into memory, and finally revoke the extensions. The WebContent process will then have read access to preferences through the mapped memory region without having access to the preference services. Also preference updates will be reflected in the WebContent process, since the memory region will contain the updated value of preferences. There is no longer any need to push preference values from the UI process.
Created attachment 398504 [details] Patch
Created attachment 398507 [details] Patch
Created attachment 398516 [details] Patch
Comment on attachment 398516 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=398516&action=review > Source/WebKit/ChangeLog:10 > + Initially, preference services were blocked by using CFPrefs direct mode. However, it is possible to keep denying preference services > + without using direct mode by issuing temporary extensions to preference services. On startup of the WebContent process, consume these > + extensions, then perform a dummy preference request to map preferences into memory, and finally revoke the extensions. The WebContent How does revoking the extension achieve our security goal? My understanding is that, if we consume a sandbox extension to "com.apple.cfprefsd.agent" and "com.apple.cfprefsd.daemon", and then connect to them, and then revoke the extension, we will end up with an open connection to these daemons. If so, revoking the extensions will prevent new connections from being made, but will not close the existing connections, which can still be used to send malicious messages. > Source/WebKit/ChangeLog:16 > + No new tests, covered by existing API tests in PreferenceChanges.mm. How does this approach handle preference change notifications? > Source/WebKit/WebProcess/cocoa/WebProcessCocoa.mm:207 > + // Make a dummy CFPrefs request to map preferences into memory > + CFPreferencesCopyAppValue(CFSTR("AppleLanguages"), CFSTR("kCFPreferencesAnyApplication")); How does this read of the AppleLanguages preference enable access to the other preferences we might need?
(In reply to Geoffrey Garen from comment #4) > Comment on attachment 398516 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=398516&action=review > > > Source/WebKit/ChangeLog:10 > > + Initially, preference services were blocked by using CFPrefs direct mode. However, it is possible to keep denying preference services > > + without using direct mode by issuing temporary extensions to preference services. On startup of the WebContent process, consume these > > + extensions, then perform a dummy preference request to map preferences into memory, and finally revoke the extensions. The WebContent > > How does revoking the extension achieve our security goal? > > My understanding is that, if we consume a sandbox extension to > "com.apple.cfprefsd.agent" and "com.apple.cfprefsd.daemon", and then connect > to them, and then revoke the extension, we will end up with an open > connection to these daemons. If so, revoking the extensions will prevent new > connections from being made, but will not close the existing connections, > which can still be used to send malicious messages. > Ah, good catch! This patch is invalid, then.
Comment on attachment 398516 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=398516&action=review >>> Source/WebKit/ChangeLog:10 >>> + extensions, then perform a dummy preference request to map preferences into memory, and finally revoke the extensions. The WebContent >> >> How does revoking the extension achieve our security goal? >> >> My understanding is that, if we consume a sandbox extension to "com.apple.cfprefsd.agent" and "com.apple.cfprefsd.daemon", and then connect to them, and then revoke the extension, we will end up with an open connection to these daemons. If so, revoking the extensions will prevent new connections from being made, but will not close the existing connections, which can still be used to send malicious messages. > > Ah, good catch! This patch is invalid, then. Setting review- based on this exchange.