marylinh / seccompsandbox

Automatically exported from code.google.com/p/seccompsandbox
BSD 3-Clause "New" or "Revised" License
0 stars 0 forks source link

Allow libraries to be patched before fork(), before enabling sandbox #9

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago
Currently, in Chromium, enabling the seccomp sandbox is done entirely
after forking from the zygote process, and this includes patching
libraries.  However, it would be good if patching libraries could be
done before fork().  This would have two advantages:

 1) Performance:  Patching libraries only once would save time and memory.

 2) Security, when using the SUID sandbox:  Currently the zygote
    process needs to keep a directory FD for /proc, because the
    seccomp sandbox needs /proc/self/maps in order to do library
    patching.

    /proc conveys a lot of authority, so this makes the SUID sandbox
    less secure than it would otherwise be, even if this FD is only
    held by the zygote process and not its children.

    If the zygote process had Breakpad enabled (although it's not
    supposed to), a SUID-sandboxed process could take control of the
    zygote (and hence its /proc FD) by sending it a signal, waiting
    for the zygote to make itelf dumpable using prctl(), and then
    taking control of the zygote using ptrace().

In order to allow patching before fork(), we would need to add a
global flag to the syscall interceptor to pass through syscalls
unaltered until the sandbox has been enabled fully.

Original issue reported on code.google.com by mseaborn@chromium.org on 18 Oct 2010 at 1:09

GoogleCodeExporter commented 8 years ago
Actually, having thought about this more, this is not going to work
with Native Client at the moment, when Native Client's sel_ldr process
is forked from Chromium's zygote process.  NaCl will not work with the
seccomp sandbox's syscall interception set up, even if the
interception has a pass-through mode -- or at least, if it works, it
will make the NaCl sandbox insecure.  See
http://code.google.com/p/nativeclient/issues/detail?id=487

Also see http://code.google.com/p/chromium/issues/detail?id=55599 for
some more background.

Original comment by mseaborn@chromium.org on 18 Oct 2010 at 1:21