Saving a DMD output kills the RDD process
Categories
(Core :: Security: Process Sandboxing, defect, P2)
Tracking
()
Tracking | Status | |
---|---|---|
firefox79 | --- | fixed |
People
(Reporter: emilio, Assigned: jld)
Details
Attachments
(1 file)
$ cat dmd.out | python2 ./tools/rb/fix_stacks.py
Sandbox: seccomp sandbox violation: pid 303621, tid 303621, syscall 72, args 23 3 140349391152101 18446744073709550146 0 2068580765. Killing process.
Sandbox: crash reporter is disabled (or failed); trying stack trace:
Sandbox: frame #01: ??? (/lib64/libc.so.6 + 0xf7634)
DMD[302709] opened /tmp/dmd-1589890829-303353.json.gz for writing
Sandbox: frame #02: __libc_fcntl64 (/lib64/libc.so.6 + 0xf2a28)
Sandbox: frame #03: fdopen (/lib64/libc.so.6 + 0x763ac)
DMD[302709] opened /tmp/dmd-1589890829-303176.json.gz for writing
DMD[302709] opened /tmp/dmd-1589890829-303169.json.gz for writing
DMD[302709] opened /tmp/dmd-1589890829-303162.json.gz for writing
DMD[302709] opened /tmp/dmd-1589890829-303155.json.gz for writing
DMD[302709] opened /tmp/dmd-1589890829-303148.json.gz for writing
Sandbox: frame #04: mozilla::ipc::FileDescriptorToFILE(mozilla::ipc::FileDescriptor const&, char const*) (/home/emilio/src/moz/gecko-2/ipc/glue/FileDescriptorUtils.cpp:88)
Sandbox: frame #05: mozilla::dom::MemoryReportRequestClient::Run() (/home/emilio/src/moz/gecko-2/dom/ipc/MemoryReportRequest.cpp:162)
Sandbox: frame #06: mozilla::dom::MemoryReportRequestClient::Start(unsigned int, bool, bool, mozilla::Maybe<mozilla::ipc::FileDescriptor> const&, nsTSubstring<char> const&, std::function<void (mozilla::dom::MemoryReport const&)> const&, std::function<bool (unsigned int const&)> const&) (/home/emilio/src/moz/gecko-2/xpcom/base/nsISupportsImpl.h:295)
Sandbox: frame #07: mozilla::RDDParent::RecvRequestMemoryReport(unsigned int const&, bool const&, bool const&, mozilla::Maybe<mozilla::ipc::FileDescriptor> const&) (/home/emilio/src/moz/gecko-2/dom/media/ipc/RDDParent.cpp:170)
Sandbox: frame #08: mozilla::PRDDParent::OnMessageReceived(IPC::Message const&) (/home/emilio/src/moz/gecko-2/obj-dmd-no-sccache/ipc/ipdl/PRDDParent.cpp:0)
Sandbox: frame #09: mozilla::ipc::MessageChannel::DispatchAsyncMessage(mozilla::ipc::ActorLifecycleProxy*, IPC::Message const&) (/home/emilio/src/moz/gecko-2/ipc/glue/MessageChannel.cpp:2187)
Sandbox: frame #10: mozilla::ipc::MessageChannel::DispatchMessage(IPC::Message&&) (/home/emilio/src/moz/gecko-2/ipc/glue/MessageChannel.cpp:0)
Sandbox: frame #11: mozilla::ipc::MessageChannel::RunMessage(mozilla::ipc::MessageChannel::MessageTask&) (/home/emilio/src/moz/gecko-2/ipc/glue/MessageChannel.cpp:0)
Sandbox: frame #12: mozilla::ipc::MessageChannel::MessageTask::Run() (/home/emilio/src/moz/gecko-2/ipc/glue/MessageChannel.cpp:1991)
Sandbox: frame #13: nsThread::ProcessNextEvent(bool, bool*) (/home/emilio/src/moz/gecko-2/obj-dmd-no-sccache/dist/include/mozilla/RefPtr.h:286)
Sandbox: frame #14: NS_ProcessNextEvent(nsIThread*, bool) (/home/emilio/src/moz/gecko-2/xpcom/threads/nsThreadUtils.cpp:501)
Sandbox: frame #15: mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate*) (/home/emilio/src/moz/gecko-2/ipc/glue/MessagePump.cpp:0)
Sandbox: frame #16: MessageLoop::Run() (/home/emilio/src/moz/gecko-2/ipc/chromium/src/base/message_loop.cc:291)
Sandbox: frame #17: nsBaseAppShell::Run() (/home/emilio/src/moz/gecko-2/widget/nsBaseAppShell.cpp:139)
Sandbox: frame #18: XRE_RunAppShell() (/home/emilio/src/moz/gecko-2/toolkit/xre/nsEmbedFunctions.cpp:909)
Sandbox: frame #19: MessageLoop::Run() (/home/emilio/src/moz/gecko-2/ipc/chromium/src/base/message_loop.cc:291)
Sandbox: frame #20: XRE_InitChildProcess(int, char**, XREChildData const*) (/home/emilio/src/moz/gecko-2/toolkit/xre/nsEmbedFunctions.cpp:744)
Sandbox: frame #21: main (/home/emilio/src/moz/gecko-2/ipc/contentproc/plugin-container.cpp:56)
Sandbox: frame #22: __libc_start_main (/lib64/libc.so.6 + 0x27042)
Sandbox: frame #23: _start (/home/emilio/src/moz/gecko-2/obj-dmd-no-sccache/dist/bin/firefox + 0x2873e)
Sandbox: frame #24: ??? (???:???)
Sandbox: end of stack.
Updated•5 years ago
|
Assignee | ||
Comment 1•5 years ago
|
||
3 is F_GETFL
; we allow this in some process types already. glibc seems to be using it in fdopen
to check the read/write/append status of the fd against the requested stdio file mode, which is a reasonable thing to allow in the common policy.
Assignee | ||
Comment 2•5 years ago
|
||
I have a patch (but it's not fully tested yet).
Assignee | ||
Comment 3•5 years ago
|
||
So this is a little nontrivial, because the RDD policy copied the GMP policy's fcntl
handler, which overrides the common policy. There are several ways to deal with that, but I think the restricted subset of F_[GS]ETF[DL]
currently allowed by the content policy can just become the default (and GMP can continue overriding it with the handler).
Assignee | ||
Comment 4•5 years ago
|
||
Content processes allow a restricted subset of F_{GET,SET}{FD,FL} that
prevents setting unknown or known-unsafe flags, which was copied to the
socket process policy; this patch moves it to the common policy and
removes RDD's copy of GMP's override.
The immediate reason for this is DMD using F_GETFL via fdopen to use a
file descriptor passed over IPC, but in general this should be safe and
it's a reasonable thing to expect to be able to use.
Comment 6•5 years ago
|
||
bugherder |
Description
•