On Tue, Sep 24, 2019 at 06:43:51AM -0600, Theo de Raadt wrote: > joshua stein <j...@openbsd.org> wrote: > > > I don't like the pledge and unveil settings being in preferences for > > these and other reasons, but it's currently what Mozilla people are > > asking for in order to get reviewed/upstreamed and is how their own > > sandboxing on other platforms is controlled > > (security.sandbox.content.level can be changed on Linux for > > example). > > > > In the end, this task of upstreaming these patches may be too > > difficult or insecure and I'll go back to reading from root-owned > > files in /etc/firefox like our Chromium port does, having to carry > > our own patches for each release. I'm not sure what the plan is > > yet. > > > I'm still very surprised. Their proposed model completely lacks any > security, as it ignores obvious escalation techniques. > > The unveil/pledge/sandbox variables in question establish a > process-containment. Let's say the attacker is aware of a browser bug > which can achieve code-execution, well he will change those variables to > request less (or no) containment, for FUTURE BROWSER RESTARTS. At that > point he can crash the browser, which the user will restart WITHOUT > CONTAINMENT, and the browser's default will revisit the same attacker > pages permitting a continuation of the attack without sandbox constraints. > > If a program can disable it's own security policy, well then it isn't a > security policy. > > I suggest doing as they ask to get it integrated, and then maintain a > few lines of patch that causes root-owned-files to override the fragile > user-selected options.
All good ideas need to be discussed with upstream at https://bugzilla.mozilla.org/show_bug.cgi?id=1580271. I spent months upstreaming tons of patches, and i'm not carrying more of them..
