On Tue, Sep 24, 2019 at 11:13:38AM -0600, Theo de Raadt wrote: > Landry Breuil <lan...@openbsd.org> wrote: > > > 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.. > > Glad to se you've ignored the technical discussion and maintain the > opinion it must be upstream.
I'm 'ignoring' the technical discussion because i dont feel qualified to have an opinion about it, nor do i have the time/energy to work on it. At that point, my best advice is to work with upstream because qualified people there might have a valuable technical opinion. Even if you doubt it. You're of course free to disagree with me, and find someone else to do my work if you dont like the way i do it. > My personal opinion on this. I've contributed a technical point and > look at the result, I'm told to shut up and talk to some people I don't > care to talk to. Count me out, I will not run this trash fire. Sorry, in ports land we've always been told to work with upstream .. https://www.openbsd.org/faq/ports/guide.html#PortsComplex as of now even says 'Make sure the software authors are aware of your tweaks to make it run on OpenBSD. You must endeavor to get OpenBSD patches into the next release of the software. Otherwise, you can be prepared to rewrite most of your patches from scratch every release.'. Landry
