Scott van Looy wrote:
Absolutely not! The way people using a distribution get updates is
with 'yum update' or the equivalent. Otherwise, only experts will
have anything updated. And the config files should be constructed such
that most local changes are merged from /etc/sysconfig and thus
updated files in an RPM can replace the previous unmodified copies.
so if an exploit is discovered we should just sit back and be hacked
until someone else fixes it for us? That's just plain lazy
Have you re-written the kernel yourself after each exploit was
discovered? I didn't, so I guess that makes me lazy. One of the
reasons for picking a distribution should be how much you trust it to
supply timely updates.
Sendmail is installed by default, you seem to want to have it able to
connect to the internet by default too,
No, I want consistency among the network services. The way you enable
it should match the way you'd enable sshd to listen to the network, or
apache, cups, or dovecot, or perhaps the way you set up named as a
caching nameserver.
I'd say this isn't what most
users will require of it, indeed, many users don't even bother with
sendmail. Therefore it shouldn't be the default. Or people will get
exploited. Because we aim, by default, to have few open ports.
Note that sshd, dovecot, and cups have had possible exploits in various
versions and thus should have equivalent treatment.
The point of security is to have as few ways to compromise a system
available by default as possible. It makes sense to have a feature not
available by default that isn't going to be needed by the majority of
users, no?
The way to get security is to make the system consistent and easily
understandable. If users need to hand-edit complex config files for
common operations you haven't accomplished that. How, for example,
would you advise a user to check for whether sendmail was active on the
network or not, and how to change it? Why should this differ from what
you'd say about dovecot? If every program is a special case, few people
are going to understand the system well enough to keep it secure.
--
Les Mikesell
lesmikesell@xxxxxxxxx
