Tugger the SLUGger!SLUG Mailing List Archives

Re: [SLUG] Security and the default settings of common linux distributions


> Ken Caldwell wrote:
>
> Dennis E. Powell argues that common distributions leave services on by
> default unnecessarily and fail to adequately document what services they
> provide and what these services are used for.


http://www.linuxplanet.com/linuxplanet/opinions/2083/3/


> Maybe some subscribers to this list might like to comment on the
> article.  It could be the start of an educational thread.


Okay then, I'll bite. ;)

---

"The Default Should Be Off."

And not just off - purged. RedHat's latest releases are moving in this
direction; finally telnet/telnetd and similar packages have been split so
you don't have to have the server executables installed.

---

"Linux distributors, I think, do not for the most part believe that they are
producing a desktop operating system."

I've had the unfortunate experience of being chastised by a Windows NT fan
because we "all try to shove Linux in everywhere and anywhere: servers,
desktops, TV's, even handhelds - it's idiotic". Whilst there are obvious
technical faults in that assessment, one could quite easily apply it to
distributions, and be right.

My desktop is not my server - I do not want the same things on my desktop
that I would on my server! I think installation routines should be as simple
as doofus clicking - three clicks to a fresh Linux desktop. Install first,
ask questions later; which you can do using the advanced package management
features most distributions have.

Desktop installs should not include any 'services' -> case in point? Win9x
without filesharing switched on.

If you're going to sell Linux as a desktop OS, do it properly. Corel (so I
hear) has a particularly well targeted desktop distro. Others have a
confusing mass of packages, badly labelled and hopelessly documented where
it counts -> during installation.

Most SLUGgers would take a different approach to their desktops to the
'average joe' computer user. Many - like myself - run a development machine,
on which the lines between server and desktop are blurred.

---

Personal IPChains (warning: Debian specific implementation ideas ahead)

This is an idea I've been toying with for a while now, however I certainly
don't have the skills to do it.

One of the remarkable things I've seen installing OpenBSD and Debian, is the
amount of 'chit-chat' that goes on during installation. They actually say,
"Oh, hey, I'm installing this, and configuring this, can I do this, this, or
this for you?" I mentioned the Exim set up for Debian earlier this week,
which asks you what sort of use you'd have with an MTA in *simple human
terms*. That was cool.

Anand tells me that Debconf will be used to configure every package that
needs it in Woody -> very cool. I'm sure he (or one of our other
representative Debian Weenies) can explain it a bit more for us (nudge,
nudge). And this is where the idea comes in:

Have a package called pipchains, which a contains simple startup
configuration, and one config file for input into ipchains. The original
file will be locked down very tight, not allowing for any 'services'.

Each package maintainer would then have a responsibility to add rules for
their applications if required, say apache and port 80. Yes, some packages
will require different kinds of rules, but debconf can handle all of those
questions quite easily. Sure, some apps could have strange dependencies with
their ipchains rules, but due to the 'subsystems' view of the world in
Debian, and its already well hashed out system, this wouldn't present too
much of a problem.

Obviously, this would only be of use on desktop machines, and servers with
basic functionality, plus, by simply uninstalling pipchains, you return to
your previously fully user-configurable environment. No sweat.

---

Quick points:

* Get rid of sendmail on desktop-like machines. Replace it with something
  minimal, because - even if you're a newbie and use mailers with built in
  SMTP interfaces - you still need an MTA for system-level tasks, and
  virtual RMS reports (highly necessary).

* Make everything install with only local interfaces enabled, unless
  specifically asked. Think MySQL and PostgreSQL, which by default on most
  distros are open to TCP/IP connections from The Entire World.

* Be talkative during configuration time (not necessarily initial
  installation time). Like OpenBSD and Debian, this leads to greater
  understanding of the system as a whole.


I think that's all... I slept in the middle of writing this, so I'm hoping
it's coherent.

- Jeff


-- jdub@xxxxxxxxxxx ----------------------- http://linux.org.au/installfest/
                                                       http://linux.conf.au/
   I am Jack's implicit trust of ActiveX & VBScript.     http://slug.org.au/