From owner-freebsd-security@freebsd.org Wed Oct 26 09:42:22 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 ABB3CC1E32C for ; Wed, 26 Oct 2016 09:42:22 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 6F418686; Wed, 26 Oct 2016 09:42:22 +0000 (UTC) (envelope-from des@des.no) Received: from desk.des.no (smtp.des.no [194.63.250.102]) by smtp.des.no (Postfix) with ESMTP id 05B64105DB; Wed, 26 Oct 2016 09:42:15 +0000 (UTC) Received: by desk.des.no (Postfix, from userid 1001) id CC7F34312E; Wed, 26 Oct 2016 11:42:14 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: CeDeROM Cc: "Robert N. M. Watson" , freebsd-security@freebsd.org, Pawel Jakub Dawidek Subject: Re: FreeBSD Security Advisory FreeBSD-SA-16:15.sysarch [REVISED] References: <20161025173641.BCDFD1911@freefall.freebsd.org> <20161026042748.GG60006@garage.freebsd.pl> <20161026061504.GH60006@garage.freebsd.pl> <0717BEFA-4E65-4990-AC50-FD80681C110C@FreeBSD.org> Date: Wed, 26 Oct 2016 11:42:14 +0200 In-Reply-To: (cederom@tlen.pl's message of "Wed, 26 Oct 2016 11:22:44 +0200") Message-ID: <868ttbwio9.fsf@desk.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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 09:42:22 -0000 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. 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. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no