Re: Packages should not Conflict on the basis of duplicate functionality
- To: firstname.lastname@example.org
- Subject: Re: Packages should not Conflict on the basis of duplicate functionality
- From: The Doctor What <email@example.com>
- Date: Fri, 1 Oct 1999 03:13:56 -0500
- Message-id: <19991001031356.T30487@gerf.gerf.org>
- In-reply-to: <19990930080532.D777@taz.net.au>; from Craig Sanders on Thu, Sep 30, 1999 at 08:05:32AM +1000
- References: <firstname.lastname@example.org> <19990924233428.O9912@gerf.gerf.org> <19990925011111.B17910@usatoday.com> <19990927130557.A8109@taz.net.au> <19990927032154.A30222@usatoday.com> <19990929065601.B25093@taz.net.au> <email@example.com> <19990929155137.E30440@taz.net.au> <19990929063915.F19626@justice.loyola.edu> <19990930080532.D777@taz.net.au>
On Thu, Sep 30, 1999 at 08:05:32AM +1000, Craig Sanders wrote:
> On Wed, Sep 29, 1999 at 06:38:55AM -0400, Michael Stone wrote:
> > The fantasy is over--WELCOME TO REAL LIFE! It turns out that some
> > people install Linux without preexisting knowledge of how to securely
> > administer a Unix machine.
> sorry, it's you who needs to wake up to the real world.
Excuse me. I work for TurboLinux. We make it an EXPLICIT policy to
disable all daemons, for Workstation and Server products. We also provide
a tool to manage these (turboservices and turbonetcfg).
I used to work for Tandem Computers, Tandem Computers had a similar policy
While Mr. Stone is being a little extreme, this is the real world.
This is a security issue. More than that it is a matter of choice.
> if people don't know how to administer a Unix machine then they need
> to learn fast. no amount of molly-coddling by the distribution authors
> (i.e. us) is going to obviate that essential requirement. maintaining
> security on your own systems requires personal knowledge and experience,
> it can not be done by proxy.
Since all users should know Unix anyway, let us turn off all services
This is not my position.
I'm of the opinion that it should ask as Debian has no separate "Workstation"
or "Server" set up. If it really bothers you, then maybe a global switch
that sets whether daemons should just start up or ask first.
> > When we ship a system with a bunch of stuff enabled by default,
> > we're not only putting their machine at risk but we're also creating
> > problems for everyone else who's system is attacked by someone using
> > the debian machine as a jump-off point. That's bad.
> that's bad. it's also bullshit. enabling daemons by default is not
> inherently a security problem.
I would beg to differ. In some environments, having an unconfigured
server running for 30 seconds is too much. And don't tell me to
pulling the net cable. What if it's being installed via the net?
But security is not the only issue here. Choice is. Have a policy that
says all daemons should ask:
Should it start now, or be configured later
Should it use inetd, or run stand-alone?
Should it use the default port(s)? Or something else?
> if they don't need it then they shouldn't install the package.
There is a difference between installing a package, reading
the docs, seeing how it works in loop-back or an alternate port, and
installing a package to run now.
> why run debian (with all it's useful tools like update-inetd and
> update-rc.d and so on) if you're going to throw away those advantages?
If we ask the questions upon initial install, set the daemon the way we
want it, how are we throwing away Debian's tools? We are getting what we
want. If we want to only use half the tools, that's our perogative.
> it's damned annoying to see people trying to force their personal
> preferences on everyone else by making loud noises about trumped up
> nebulous and vague "security" issues. it would be nicer if such FUD were
> left behind in the proprietary software world.
No kidding. Security isn't the only issue here, but it part of this
"I'm not a god, I was misquoted."
-- Lister (Red Dwarf)
The Doctor What: Un-Humble http://docwhat.gerf.org/
firstname.lastname@example.org (finger email@example.com for PGP key)