Date: Wed, 26 Oct 2016 12:00:33 +0100 From: "Robert N.M. Watson" <rwatson@FreeBSD.org> To: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= <des@des.no> Cc: CeDeROM <cederom@tlen.pl>, freebsd-security@freebsd.org, Pawel Jakub Dawidek <pjd@freebsd.org> Subject: Re: FreeBSD Security Advisory FreeBSD-SA-16:15.sysarch [REVISED] Message-ID: <376CBFFC-8BE1-4401-984E-4E8BB336FE32@FreeBSD.org> In-Reply-To: <868ttbwio9.fsf@desk.des.no> References: <20161025173641.BCDFD1911@freefall.freebsd.org> <20161026042748.GG60006@garage.freebsd.pl> <CAGMYy3v8KxuQfou0SmUNikghH-9NWfneoMPP_15F85WkDaUhKg@mail.gmail.com> <20161026061504.GH60006@garage.freebsd.pl> <0717BEFA-4E65-4990-AC50-FD80681C110C@FreeBSD.org> <CAFYkXjn39kKzcTY-pJObaVz8OGqbzCHE69kYAmRYtz5OX2kpAQ@mail.gmail.com> <868ttbwio9.fsf@desk.des.no>
next in thread | previous in thread | raw e-mail | index | archive | help
On 26 Oct 2016, at 10:42, Dag-Erling Sm=C3=B8rgrav <des@des.no> wrote: > CeDeROM <cederom@tlen.pl> writes: >> Robert N. M. Watson <rwatson@freebsd.org> writes: >>> In general, my strong recommendation is against issuing advisories >>> for local denial-of-service attacks, (..) >> I would prefer to get that information regardless of individual >> preferences. >=20 > It's not a matter of individual preference. During my time as so@ = (and > Simon's before me), this was an explicit policy. The reason is that, = as > Robert points out, there are a million ways for a trusted unprivileged > user to cause a DoS, and most of them aren't even bugs. Some of them > can be mitigated using quotas or resource limits, but far from all. I agree: it=E2=80=99s critical that security patches remain a = high-signal, low-noise venue for conservative changes for which risk has = been minimised (and carefully balanced against urgency of application). = This is especially true for kernel patches, which not only suffer higher = risk in general (it=E2=80=99s not just one application that crashes..) = but also higher impact on uptime (since they require a reboot), etc. = Risk is further increased with patches requiring reboots as they expose = greater opportunity for operator error. Starting to ship large numbers = of stability fixes via this mechanism will make it vastly harder for = users to minimise downtime, which may have a much more substantial = impact than the problem being fixed. We do have a mechanism for shipping (and also batching) stability = improvements, which is the errata note mechanism =E2=80=94 and that may = be appropriate where there are a class of related critical stability = (rather than security) problems, especially where they are seen =E2=80=9Ci= n the wild=E2=80=9D and are impacting a substantial user base, which = mitigates the former risks to some extent. For non-critical stability fixes, then there is a source of continuous = notifications and improvements available: the commit mailing lists. = Every time a commit comes through saying =E2=80=9CFix a crash when = <x>=E2=80=9D, =E2=80=9CDon=E2=80=99t dereference a bad pointer when = <y>=E2=80=9D, =E2=80=9CEliminate a resource leak when <z>=E2=80=9D, then = they are pertinent to a user trying to review and evaluate fixes =E2=80=94= but they will not have seen (and cannot, at that volume see) the level = of individual review that a security update sees. I am willing to see stability problems escalated to an errata note or = security patch if we can convince ourselves that the risk imposed by = shipping the additional patch is going to be counter-balanced by the = benefits it brings =E2=80=94 but I think that case has to be made very = carefully, because between the context for updates (rebooting real = systems) and the chances of error (whether programmer or operator), = it=E2=80=99s very easy for the cost to outweigh the benefit much of the = time. Robert=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?376CBFFC-8BE1-4401-984E-4E8BB336FE32>