Linux Sandbox: add resource limits to NaCl

components/nacl/loader/sandbox_linux/nacl_sandbox_linux.cc

Index: components/nacl/loader/sandbox_linux/nacl_sandbox_linux.cc
diff --git a/components/nacl/loader/sandbox_linux/nacl_sandbox_linux.cc b/components/nacl/loader/sandbox_linux/nacl_sandbox_linux.cc
index 44cb4f57b8d2153ab4157bbe7a4f861527588a8a..942a1e2dbf83dbd275fb5f49bf4e7c7c6a975198 100644
--- a/components/nacl/loader/sandbox_linux/nacl_sandbox_linux.cc
+++ b/components/nacl/loader/sandbox_linux/nacl_sandbox_linux.cc
@@ -11,6 +11,8 @@
 #include <sys/types.h>
 #include <unistd.h>
 
+#include <limits>
+
 #include "base/basictypes.h"
 #include "base/callback.h"
 #include "base/command_line.h"
@@ -28,6 +30,7 @@
 #include "sandbox/linux/services/credentials.h"
 #include "sandbox/linux/services/namespace_sandbox.h"
 #include "sandbox/linux/services/proc_util.h"
+#include "sandbox/linux/services/resource_limits.h"
 #include "sandbox/linux/services/thread_helpers.h"
 #include "sandbox/linux/suid/client/setuid_sandbox_client.h"
 
@@ -69,6 +72,27 @@ bool MaybeSetProcessNonDumpable() {
   return prctl(PR_GET_DUMPABLE) == 0;
 }
 
+void RestrictAddressSpaceUsage() {
+#if defined(ADDRESS_SANITIZER) || defined(MEMORY_SANITIZER) || \
+    defined(THREAD_SANITIZER)
+  // Sanitizers need to reserve huge chunks of the address space.
+  return;
+#endif
+
+  // Add a limit to the brk() heap that would prevent allocations that can't be

[Mark Seaborn, 2015/02/13 17:11:54]

This probably has no benefit, because glibc will fall back to mmap() when brk()
allocations start failing.  You could perhaps add a comment along the lines of
"what the hell, might as well do this just in case it helps". :-)

[jln (very slow on Chromium), 2015/02/13 18:00:05]

Does NaCl always uses glibc malloc and not tcmalloc?

In tcmalloc I tuned that a while back and it was different between 32 bits and
64 bits and Release and Debug.

Done in any case!

+  // indexed by an int. This helps working around typical security bugs.
+  const rlim_t kNewDataSegmentMaxSize = std::numeric_limits<int>::max();
+  CHECK(sandbox::ResourceLimits::Lower(RLIMIT_DATA, kNewDataSegmentMaxSize));
+
+#if defined(ARCH_CPU_64_BITS)
+  // 128 GB.

[Mark Seaborn, 2015/02/13 17:11:54]

Can you add some explanation of how we picked this, using my explanation from
the issue, please?  i.e. Mention the 88GB minimum for x86-64 NaCl.

[jln (very slow on Chromium), 2015/02/13 18:00:05]

Done.

+  const rlim_t kNewAddressSpaceLimit = 1UL << 37;
+#else
+  const rlim_t kNewAddressSpaceLimit = std::numeric_limits<uint32_t>::max();

[Mark Seaborn, 2015/02/13 17:11:54]

Well, this is no limit at all. :-)  You might as well leave out the call in this
case and save a few bytes of code size.

[jln (very slow on Chromium), 2015/02/13 18:00:05]

This is true because we're enabling this as part of the "layer-2" sandbox (with
seccomp).

But if we didn't have seccomp, this is definitely useful on IA32 if running
under a 64 bits kernel. I'll keep itn as it's nice to not have to rely on
seccomp and have some security in depth.

I added a comment.

[Mark Seaborn, 2015/02/13 18:33:41]

Ah, good point.  I didn't think of that.

+#endif
+  CHECK(sandbox::ResourceLimits::Lower(RLIMIT_AS, kNewAddressSpaceLimit));
+}
+
 }  // namespace
 
 NaClSandbox::NaClSandbox()
@@ -153,6 +177,8 @@ void NaClSandbox::InitializeLayerTwoSandbox(bool uses_nonsfi_mode) {
   CHECK(IsSingleThreaded());
   CheckForExpectedNumberOfOpenFds();
 
+  RestrictAddressSpaceUsage();
+
   base::ScopedFD proc_self_task(GetProcSelfTask(proc_fd_.get()));
 
   if (uses_nonsfi_mode) {