update

Sun Sep 28 17:26:33 UTC 2014

----- Original Message -----
> From: "Keith Medcalf" <kmedcalf at dessus.com>

> >From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of
> >Valdis.Kletnieks at vt.edu

> >On Sat, 27 Sep 2014 21:10:28 -0400, Jay Ashworth said:
> >
> >> I haven't an example case, but it is theoretically possible.
> >
> >The sendmail setuid bug, where it failed to check the return code
> >because it was *never* possible for setuid from root to non-root to
> >fail...
> >... until the Linux kernel grew new features.

> This is another case where a change was made.
> 
> If the change had not been made (implement the new kernel) then the
> vulnerability would not have been introduced.
> 
> The more examples people think they find, the more it proves my
> proposition. Vulnerabilities can only be introduced or removed through
> change. If there is no change, then the vulnerability profile is
> fixed.

[ quoting fixed because you were too lazy ]

We have established, Keith, that you place the boundary of the object
for which an end-deployer has administrative control in a different place
for the purpose of assigning blame than most other people seem to, yes.

The sendmail maintainers are *NOT RESPONSIBLE* for avoiding exploits that
cannot happen in any available or planned deployment environment, nor for
decisions made by the creators of those environments which *cause their
code to become exploitable ex-post-facto*.  That's the point which I see
being made here.  If that's orthogonal to your argument, so be it.

Could we drop this now?

Cheers,
-- jra

-- 
Jay R. Ashworth                  Baylink                       jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates       http://www.bcp38.info          2000 Land Rover DII
St Petersburg FL USA      BCP38: Ask For It By Name!           +1 727 647 1274