On Tue, Sep 24, 2019 at 12:57:57PM -0600, Theo de Raadt wrote:
> Landry Breuil <landry@openbsd.org> wrote:
>
> > On Tue, Sep 24, 2019 at 11:13:38AM -0600, Theo de Raadt wrote:
> > > Landry Breuil <landry@openbsd.org> wrote:
> > >
> > > > On Tue, Sep 24, 2019 at 06:43:51AM -0600, Theo de Raadt wrote:
> > > > > joshua stein <jcs@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.
Then please enlighten them.
> 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.
Feel free to correct my mistakes there then, or find someone to do so.
I'm done working on those diffs.
No comments:
Post a Comment