Re: CVS commit: src

[Maxime Villard <max%m00nbsd.net@localhost>]

Le 20/12/2019 à 20:52, Martin Husemann a écrit :
> On Fri, Dec 20, 2019 at 07:54:36PM +0100, Maxime Villard wrote:
> > Alright, fair enough. I will revert my removal over the week-end, because it
> > hasn't received sufficient public discussion.
>
> Thank you!
>
> > As well, I will revert secteam's
> > killing of the feature, because there has been no public discussion on that at
> > all.
>
> Please do not. You *do* have a point here, but:
>
>   1) public discussion upfront for a security issue is not always possible,
>      as you are well aware

I'm afraid that's no excuse, in that several of the security issues in the
past have had to be discussed publicly. (On your own personal insistence,
by the way, and I see no reason why the policy would change all of a
sudden just because you personally decided otherwise.)

>   2) there has been a public security advisory which assumes this change
>      and would need to be revised in case of reversal

This only means secteam doubled down in being wrong.

Specifically, it seems to me that removing /dev/filemon would have been
sufficient, instead of removing the kmod. People could re-create
/dev/filemon with minimal effort, should they be interested in the feature.
As opposed to that, rebuilding a kmod is a much bigger effort.

So, in addition to the fact that the disabling of filemon hasn't been
discussed at all, it seems to me it was disabled the wrong way.

If you're serious one minute about doing things correctly with consensus,
secteam's commit should be reverted immediately, especially considering
that secteam's solution seems to be technically the least preferable,
since we apparently care about the users of filemon.

Obviously, if we were even more serious here, we would all understand that
in the end filemon should be removed completely and that secteam's only
mistake was to do only half the job. But you prefer to go the procedural
bullshit way, so let's go down that path together.

Regarding the SA, local DoSes are not considered security issues, yet for
some reason the advisory mentions that as a security problem; the real
problem with the races here is undefined behavior, which can separately
lead to memory disclosures and privilege escalations, both being real
security issues.

Notice also the gross typo in the title; it's "escalation", people, not
"escallation".

Maxime