1489796 - MOZ_CRASH(Hit fatal chromium sandbox condition.) on local build because of file system junction

Status: RESOLVED FIXED

(Core :: Security: Process Sandboxing, defect, P2)

Description

[Jan Henning [:JanH]]

> firefox.exe!logging::LogMessage::~LogMessage() Zeile 120	C++
> firefox.exe!sandbox::FileSystemPolicy::GenerateRules(const wchar_t * name, sandbox::TargetPolicy::Semantics semantics, sandbox::LowLevelPolicy * policy) Zeile 92	C++
> firefox.exe!sandbox::PolicyBase::AddRuleInternal(sandbox::TargetPolicy::SubSystem subsystem, sandbox::TargetPolicy::Semantics semantics, const wchar_t * pattern) Zeile 708	C++
> firefox.exe!sandbox::PolicyBase::AddRule(sandbox::TargetPolicy::SubSystem subsystem, sandbox::TargetPolicy::Semantics semantics, const wchar_t * pattern) Zeile 389	C++
> xul.dll!mozilla::AddCachedDirRule(sandbox::TargetPolicy * aPolicy, sandbox::TargetPolicy::Semantics aAccess, const mozilla::UniquePtr<nsTString<char16_t>,mozilla::DefaultDelete<nsTString<char16_t> > > & aBaseDir, const nsTLiteralString<char16_t> & aRelativePath) Zeile 282	C++
> xul.dll!mozilla::SandboxBroker::SetSecurityLevelForContentProcess(int aSandboxLevel, bool aIsFileProcess) Zeile 505	C++
> xul.dll!mozilla::ipc::GeckoChildProcessHost::PerformAsyncLaunchInternal(std::vector<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::allocator<std::basic_string<char,std::char_traits<char>,std::allocator<char> > > > & aExtraOpts) Zeile 949	C++
> xul.dll!mozilla::ipc::GeckoChildProcessHost::PerformAsyncLaunch(std::vector<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::allocator<std::basic_string<char,std::char_traits<char>,std::allocator<char> > > > aExtraOpts) Zeile 547	C++
> xul.dll!mozilla::ipc::GeckoChildProcessHost::RunPerformAsyncLaunch(std::vector<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::allocator<std::basic_string<char,std::char_traits<char>,std::allocator<char> > > > aExtraOpts) Zeile 555	C++

The crash-triggering call of FileSystemPolicy::GenerateRules is being done with a name of "d:\\Users\\Jan\\AppData\\Roaming\\Mozilla\\SystemExtensionsDev\\*" and semantics of "FILES_ALLOW_READONLY (1)". Because a comment there mentions reparse points [1], I'm guessing that this problem is being hit because I used an NTFS file system junction to move AppData\Roaming\Mozilla onto an additional SSD drive I recently installed in my computer.

[1] https://dxr.mozilla.org/mozilla-central/rev/c2e3be6a1dd352b969a45f0b85e87674e24ad284/security/sandbox/chromium/sandbox/win/src/filesystem_policy.cc#90-92

Comment 1

[Bob Owen (:bobowen)]

Yes, that will probably be it.
At the moment, we set up rules to access the chrome directory in the profile and various extension directories.
The sandbox code doesn't allow those rules to be reparse points, which includes junction points.

I had to make a change to resolve the bin directory for similar reasons, so we'll probably have to do the same for the profile dir.
It has to be done in the directory service, so that the requests from the child process will match the rules we set up.

As a work around, if you change the path to the real one in profiles.ini (setting IsRelative=0), does that fix the problem?

Comment 2

[Jan Henning [:JanH]]

I don't think your suggestion would help: The (first) faulting path is %appdata%\Mozilla\SystemExtensionsDev, i.e. nothing that looks like it would be controlled by profiles.ini. (Also the actual profile itself that is used by the local build is within the objdir anyway, so not affected by any junctions in my case).
As a workaround, I've simply disabled the sandbox completely for my local builds.

Comment 3

[Bob Owen (:bobowen)]

(In reply to Jan Henning [:JanH] from comment #2)
> I don't think your suggestion would help: The (first) faulting path is
> %appdata%\Mozilla\SystemExtensionsDev, i.e. nothing that looks like it would
> be controlled by profiles.ini. (Also the actual profile itself that is used
> by the local build is within the objdir anyway, so not affected by any
> junctions in my case).
> As a workaround, I've simply disabled the sandbox completely for my local
> builds.

Ah, I'd forgotten that not all of them were in the profile dir.
I'll try and pick this up soon.

Comment 4

[Bob Owen (:bobowen)]

Hi Jan, sorry it's taken so long for me to look at this.

I've pushed a patch to try that resolves the junction points and symlinks for the systems extensions and dev dirs.

Would you be able to test this to see if it fixes the problem (I've not dealt with system extensions and couldn't find any docs about them):
https://treeherder.mozilla.org/#/jobs?repo=try&revision=09d1904a05654a19e135b174f17fbc2f0384057e

Comment 5

[Jan Henning [:JanH]]

> I've not dealt with system extensions and couldn't find any docs about them

Neither have I, but I've re-enabled the sandbox in my mozconfig and with your patch applied, my local build no longer crashes, so thank you for looking at this.

Comment 6

[Bob Owen (:bobowen)]

(In reply to Jan Henning [:JanH] from comment #5)
> > I've not dealt with system extensions and couldn't find any docs about them
> 
> Neither have I, but I've re-enabled the sandbox in my mozconfig and with
> your patch applied, my local build no longer crashes, so thank you for
> looking at this.

Ah, sorry I didn't realize that this was failing without doing systems extensions work.
Thanks for testing this.

Comment 7

[Bob Owen (:bobowen)]

Attachment: On Windows resolve junction points and symlinks in the sys user extensions directories

This is needed because they are currently used in sandbox rules.

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/5c1a8f06c28b
On Windows resolve junction points and symlinks in the sys user extensions directories. r=jimm

Comment 9

[Bogdan Tara[:bogdan_tara | bogdant]]

https://hg.mozilla.org/mozilla-central/rev/5c1a8f06c28b