From owner-freebsd-security@freebsd.org Wed Oct 26 11:00:37 2016 Return-Path: Delivered-To: freebsd-security@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B41C8C20A0D for ; Wed, 26 Oct 2016 11:00:37 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [198.74.231.69]) by mx1.freebsd.org (Postfix) with ESMTP id 78FB4E2C; Wed, 26 Oct 2016 11:00:37 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from kaffir.sec.cl.cam.ac.uk (kaffir.sec.cl.cam.ac.uk [128.232.18.243]) by cyrus.watson.org (Postfix) with ESMTPSA id EF02946B2A; Wed, 26 Oct 2016 07:00:35 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: FreeBSD Security Advisory FreeBSD-SA-16:15.sysarch [REVISED] From: "Robert N.M. Watson" In-Reply-To: <868ttbwio9.fsf@desk.des.no> Date: Wed, 26 Oct 2016 12:00:33 +0100 Cc: CeDeROM , freebsd-security@freebsd.org, Pawel Jakub Dawidek Content-Transfer-Encoding: quoted-printable Message-Id: <376CBFFC-8BE1-4401-984E-4E8BB336FE32@FreeBSD.org> References: <20161025173641.BCDFD1911@freefall.freebsd.org> <20161026042748.GG60006@garage.freebsd.pl> <20161026061504.GH60006@garage.freebsd.pl> <0717BEFA-4E65-4990-AC50-FD80681C110C@FreeBSD.org> <868ttbwio9.fsf@desk.des.no> To: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2016 11:00:37 -0000 On 26 Oct 2016, at 10:42, Dag-Erling Sm=C3=B8rgrav wrote: > CeDeROM writes: >> Robert N. M. Watson 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 = =E2=80=9D, =E2=80=9CDon=E2=80=99t dereference a bad pointer when = =E2=80=9D, =E2=80=9CEliminate a resource leak when =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=