On Mon, 23 Apr 2001, Kenneth E. Lussier wrote:
> What I blame RH for is the way decide to configure these packages. For
> example, on a RH system with BIND installed, named runs as root.

  As of RHL 6.2+patches onward, that has been fixed.

 More generally, this symptom is not really specific to Red Hat (although that
does not release RH from responsibility).  Your traditional Linux (or, for
that matter, Unix) daemon runs as root, even if all it is doing is handing out
the time of day.  Despite the fact that organizations (the OpenBSD project
comes to mind) have been preaching the benefits of unprivileged daemons, chroot
jails, and other relatively straight-forward protective measures for years,
almost nobody actually implements them.

  A favorite quotation of mine comes to mind: "If architects designed
buildings the way programmers write programs, the first wood-pecker to come
along would have destroyed civilization."

> The installer warns against suid binaries, packages are centrally
> maintained and audited, and security updates are released fairly quickly.

  I'm not so sure if any of that adds up to practical security benefits.  The
"warns against suid binaries" and "centrally maintained"  bits are nice and
all, but they are not improving the security of the system directly.  Your
average Debian package for a service "turns itself on" when installed, just
like most every other distro does.  I favor a "secure by default" approach,
where you have to explicitly activate the service or open up an access control
list.  Few Linux distros do this.  (For that matter, few *OSes* do this.)

  As far as releasing security updates goes, from watching LinuxToday (hardly
a scientific survey, I realize, but I take what I can get), it appears Debian,
Mandrake and Red Hat are the quickest of the lot.

-- 
Ben Scott <[EMAIL PROTECTED]>
| The opinions expressed in this message are those of the author and do not |
| necessarily represent the views or policy of any other person, entity or  |
| organization.  All information is provided without warranty of any kind.  |


**********************************************************
To unsubscribe from this list, send mail to
[EMAIL PROTECTED] with the following text in the
*body* (*not* the subject line) of the letter:
unsubscribe gnhlug
**********************************************************

Reply via email to