942695 - (desktop-seccomp-ongoing) [meta] Tracking bug for tightening the seccomp-bpf whitelist for Linux Desktop

Status: NEW

(Core :: Security: Process Sandboxing, defect)

Description

[Christoph Kerschbaumer [:ckerschb}]

Currently the seccomp filter sandboxing uses to allow syscalls [1] relies on a very open whitelist that allows to run firefox using that sandbox. Over time, we want to eliminate dangerous syscalls from that whitelist; definitely the following (probably even more):

  open
  prctl
  access
  unlink
  fsync
  socketpair
  sendmsg  
  socket
  chmod
  execve
  rename
  symlink
  connect
  quotactl
  kill
  sendto

For more information, please also see [2].

[1] http://mxr.mozilla.org/mozilla-central/source/security/sandbox/linux/seccomp_filter.h
[2] https://wiki.mozilla.org/FoxInABox

Comment 1

[Christoph Kerschbaumer [:ckerschb}]

Probably obvious, but mentioning the steps to get started to work on sandboxing for linux desktop:

> Update your .mozconfig and add those two lines:
    ac_add_options --enable-content-sandbox
    ac_add_options --enable-content-sandbox-reporter

> Enable e10s. Do this in about:config by setting:
     browser.tabs.remote = true;
  then restart your browser.

> You can apply the following patch to send the child process to sleep for 120 seconds.
  Use the 'ps' command to find the process Id, and then attach gdb once the process wakes up. 

--- a/security/sandbox/linux/Sandbox.cpp
+++ b/security/sandbox/linux/Sandbox.cpp
@@ -138,16 +138,21 @@ InstallSyscallFilter(void)
 {
   if (prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0)) {
     return 1;
   }
 
   if (prctl(PR_SET_SECCOMP, SECCOMP_MODE_FILTER, &seccomp_prog, 0, 0)) {
     return 1;
   }
+
+  printf("\n\n going to sleep...\n\n");
+  sleep(120);
+  printf("\n\n waking up ...\n\n");
+
   return 0;
 }

Comment 2

[Jed Davis [:jld] ⟨⏰|UTC-8⟩ ⟦he/him⟧]

Move process sandboxing bugs to their new, separate component.

(Sorry for the bugspam; filter on 3c21328c-8cfb-4819-9d88-f6e965067350.)

Comment 3

[Jens Stutte [:jstutte]]

Is there anything left to do here or do we want to keep this for future bugs?

Comment 4

[Jed Davis [:jld] ⟨⏰|UTC-8⟩ ⟦he/him⟧]

That is an excellent question. I'd forgotten we had this meta-bug, and there are a number of past bugs that could have been collected here. I'm tempted to say that if we never used this meta-bug for the past N years then it's not useful, but I'd like to see how many “it would be nice if we could block this” or “we should be more fine-grained about this” bugs we still have open, because at present I don't think there's a good way to find them other than browsing every open bug in the component and maybe things can be better organized than they are now.

Comment 5

[Jens Stutte [:jstutte]]

(In reply to Jed Davis [:jld] (away until 12-29) from comment #4)

That is an excellent question. I'd forgotten we had this meta-bug, and there are a number of past bugs that could have been collected here. I'm tempted to say that if we never used this meta-bug for the past N years then it's not useful, but I'd like to see how many “it would be nice if we could block this” or “we should be more fine-grained about this” bugs we still have open, because at present I don't think there's a good way to find them other than browsing every open bug in the component and maybe things can be better organized than they are now.

Where you able to get to this or should we just close?