Bug 187018 – Update Cisco Webex sandbox to make it functional

• Status: RESOLVED
• Resolution: WONTFIX
• Component: WebRTC

[youenn fablet]

Update Cisco Webex sandbox to make it functional

[youenn fablet]

Created attachment 343543 [details]
Patch

[youenn fablet]

Created attachment 343586 [details]
Patch

[Alexey Proskuryakov]

Comment on attachment 343586 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=343586&action=review

> Source/WebKit/Resources/PlugInSandboxProfiles/com.cisco.webex.plugin.gpc64.sb:37
> +    (literal "/Library/ScriptingAdditions"))

Allowing writing here seems very insecure.

> Source/WebKit/Resources/PlugInSandboxProfiles/com.cisco.webex.plugin.gpc64.sb:65
> +    (prefix "/private/var/folders"))

And this is definitely unacceptable.

[youenn fablet]

Created attachment 343668 [details]
Patch

[youenn fablet]

> > Source/WebKit/Resources/PlugInSandboxProfiles/com.cisco.webex.plugin.gpc64.sb:65
> > +    (prefix "/private/var/folders"))
> 
> And this is definitely unacceptable.

This is mandatory to make the plugin work as it is right now.
To improve on this, there would be a need to coordinate with the plugin authors.
We need to have something working to continue fiddling with the sandbox.

Brent, is there a way to add the restriction that only the folders/files that the plugin creates are actually accessible?

[youenn fablet]

Or maybe deny access to some patterns...

[EWS Watchlist]

Comment on attachment 343668 [details]
Patch

Attachment 343668 [details] did not pass win-ews (win):
Output: https://webkit-queues.webkit.org/results/8356378

New failing tests:
http/tests/security/canvas-remote-read-remote-video-blocked-no-crossorigin.html
http/tests/security/video-poster-cross-origin-crash2.html

[EWS Watchlist]

Created attachment 343696 [details]
Archive of layout-test-results from ews206 for win-future

The attached test failures were seen while running run-webkit-tests on the win-ews.
Bot: ews206  Port: win-future  Platform: CYGWIN_NT-6.1-2.9.0-0.318-5-3-x86_64-64bit

[Alexey Proskuryakov]

> Or maybe deny access to some patterns...

Yes, regexes can definitely be used for access patterns. Surely the plug-in doesn't need to write to temporary and cache files of all apps for all users.

[youenn fablet]

Created attachment 343711 [details]
Patch

[Radar WebKit Bug Importer]

<rdar://problem/41528287>

[EWS Watchlist]

Comment on attachment 343711 [details]
Patch

Attachment 343711 [details] did not pass win-ews (win):
Output: https://webkit-queues.webkit.org/results/8359738

New failing tests:
http/tests/security/canvas-remote-read-remote-video-blocked-no-crossorigin.html
http/tests/security/canvas-remote-read-remote-video-redirect.html

[EWS Watchlist]

Created attachment 343730 [details]
Archive of layout-test-results from ews206 for win-future

The attached test failures were seen while running run-webkit-tests on the win-ews.
Bot: ews206  Port: win-future  Platform: CYGWIN_NT-6.1-2.9.0-0.318-5-3-x86_64-64bit

[Alexey Proskuryakov]

Comment on attachment 343711 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=343711&action=review

> Source/WebKit/Resources/PlugInSandboxProfiles/com.cisco.webex.plugin.gpc64.sb:62
>  ;; FIXME: We should tigthen the sandbox to some tmp subfolders
>  (allow file*
>      (prefix "/private/tmp"))

:-/

> Source/WebKit/Resources/PlugInSandboxProfiles/com.cisco.webex.plugin.gpc64.sb:67
> +(allow file*
> +    (regex #"^/private/var/folders/.*/TemporaryItems")
> +    (regex #"^/private/var/folders/.*\.cache$")
> +    (regex #"^/private/var/folders/.*/mds.lock$"))

This doesn't make it substantially more secure - folders for other users are unaccessible due to POSIX permissions anyway, and this still allows access to other applications' files.

What exactly are you trying to achieve with these rules?

[youenn fablet]

Comment on attachment 343711 [details]
Patch

win error unrelated