Landry Breuil <lan...@openbsd.org> wrote: > 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.
And I'm saying I don't believe it, to me it looks like the opening comment leads the entire thread away form jcs's technically correct solution. I believe those comments have led later Mozilla people who don't fully understand pledge/unveil to echo your approach without understanding that it totally nueters the security. And as you said here, you "dont feel qualified". Yet you felt qualified enough to break jcs's diffs. I'm suggesting that ignoring the technical, and focusing on the political, being expedient at "reduction of patches", and bending over backwards to please Mozilla people who don't understand unveil/pledge, has caused harm here. It is turning a serious attempt at security feature into security theater. > 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.'. That page does not say "ignore the technical". Nor does it say "convince the upstream to incorporate useless diffs". It does not say "water down improvements".
