Re: sendmail & localhost rDNS
On Tuesday, 2009-08-11 at 10:32:04 +0200, Bernhard R. Link wrote:
> * Lupe Christoph <lupe@lupe-christoph.de> [090810 21:13]:
> > > Almost all security holes need to user to do something. (If only to
> > > power up the machine, to install some packages, to connect to the
> > > internet, to give accounts to users). The question cannot be that
> > > something has to be done do make people vulnerable, but whether properly
> > > sane and educated people can guess that something opens a security
> > > problem.
> > I interpret this to mean that there should be DSAs for all problems *made
> > possible* by Debian packages, rather than those *caused* by the package.
> What I try to tell you is that I do not share your interpretion of
> "caused".
> If bash had a bug to always include . in PATH, would that cause
> a problem or make a problem possible? (After all, noone forces you do
> switch to other peoples directories before doing ls).
That would be a defect in the package that requires no user
configuration. The equivalent of "Connect:localhost RELAY" would be this
in .bashrc: PATH=.:$PATH .
> If a webbrowser has a problem executing arbitrary stuff told by the
> website visited, is that a security problem "caused" or made possible by
> the webbrowser. (After all, if you do not visit untrusted sites, there
> is no problem).
That is a defect in the webbrowser. It requires no user configuration.
> If sshd had a bug so that "PermitRootLogin without-password" (which is not
> the default) allowed people to login without any identification as root
> instead of what it is supposed to be, would that be bug caused by ssh
> or a bug made possible by ssh?
That is a bug because sshd does not what is documented. Suppose
sshd_config had an option "PermitRootLogin always", meaning that no
password or key is required to log in as root. Would it be a bug of sshd
to include this option or a misfeature?
> So it is in my eyes to criteria at all that the user has to change some
> configuration. The question is whether this change is supposed to cause
> the effects it does and if a user can be expected to understand the
> effects.
Please go ahead and file security-related bugs against all packages that
allow the user to open security holes by changing the default
configuration.
I suppose we should agree to disagree and terminate this thread here. Of
course I will not restrict your freedom to answer to this mail, but I
will leave your reply unanswered because I believe we won't ever
agree.
Lupe Christoph
--
| There is no substitute for bad design except worse design. |
| /me |
Reply to: