Implement SharedMemory::ShareReadOnlyToProcess().

This avoids potential security holes where the renderer could be exploited and
then write into space shared by other renderers or even the browser.

I've done this on Posix by opening both a read/write and read-only file descriptor to the same file. Then ShareReadOnlyToProcess dup()s the read-only descriptor instead of the read/write one. It's an error to try to ShareReadOnly from a SharedMemory that was created from a single SharedMemoryHandle.

The test checks that operations strictly through the file handle can't get
write access to the memory. On Linux there's still a hole through /dev/fd
in the filesystem, but jln@ assures me that the sandbox prevents the
filesystem-based attack. We should eventually write an explicit test for this.

Android needs http://crbug.com/320865 figured out.

BUG=302724,320865

Review URL: https://codereview.chromium.org/27265002

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@236347 0039d316-1c4b-4281-b951-d872f2087c98

1 files changed, 7 insertions, 1 deletions

diff --git a/base/memory/shared_memory_nacl.cc b/base/memory/shared_memory_nacl.cc
index bc2a98d..93c1002 100644
--- a/base/memory/shared_memory_nacl.cc
+++ b/base/memory/shared_memory_nacl.cc
@@ -140,7 +140,13 @@ void SharedMemory::Unlock() {
 
 bool SharedMemory::ShareToProcessCommon(ProcessHandle process,
                                         SharedMemoryHandle *new_handle,
-                                        bool close_self) {
+                                        bool close_self,
+                                        ShareMode share_mode) {
+  if (share_mode == SHARE_READONLY) {
+    // Untrusted code can't create descriptors or handles, which is needed to
+    // drop permissions.
+    return false;
+  }
   const int new_fd = dup(mapped_file_);
   if (new_fd < 0) {
     DPLOG(ERROR) << "dup() failed.";