jra at baylink.com
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
> >... 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
[ 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?
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
More information about the NANOG