On 26 Oct 2016, at 10:42, Dag-Erling Smørgrav <d...@des.no> wrote: > CeDeROM <cede...@tlen.pl> writes: >> Robert N. M. Watson <rwat...@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. > > 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’s 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’s 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 — and that may be appropriate where there are a class of related critical stability (rather than security) problems, especially where they are seen “in the wild” 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 “Fix a crash when <x>”, “Don’t dereference a bad pointer when <y>”, “Eliminate a resource leak when <z>”, then they are pertinent to a user trying to review and evaluate fixes — 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 — 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’s very easy for the cost to outweigh the benefit much of the time. Robert _______________________________________________ freebsd-security@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
