Re: What about Webmin?
Yep. I'll be the third person to chime in on this one but hopefully not the last.
Webmin answers the core issues this editorial was about.
It is trivial to install, easy to use, and it's possible to add just about any admin task to it. For the most part, you won't have to since someone probably has already created a plugin for you.
If you use any Unix-style system, you really should get it and use it. It is valuable by itself, and allows you to easily get others who might be gun shy about Unix to start working with it.
Webmin simplifies managing different Unix-style systems -- even OSX and Windows (Cygwin) -- by using one set of tools per service. Use of Webmin can be a good step towards an all (or mostly all) Unix environment.
Assume the packages are hostile...
It is an axiom that lack of physical security equals no security...but that's basically what we're up against these days.
With pervasive networking, we can't assume that there's any difference between having our hands on the only key to a locked room and leaving the door unlocked. Sure, we would protect the cabling and the ability of someone to either walk off with a box or some other equipment...but the data can be compromosed in either case. That it can be more easily compromised if the room isn't locked is no longer a given.
If you're using any kind of automatic package update system, you have to assume that the packages could do some uninteneded dammage. This could be because of a trojan/virus/mole/..., unintended configuration issues, or just bad/incompatible code.
The results could be very similar, though admitedly an intentionally hostile package would likely do the most dammage since it could compromise the security of the system.
After reading the LIDS mailing list -- www.lids.org -- and considering the possibilities for intrusion, I've come to a few conclusions on how to deal with hostile packages and users or even administrators who want -- out of ignorance or intent -- to change the system in hazzardous ways.
Keep in mind that I'm recommending these types of changes for all systems, not just the firewall or some sensitive equipment stored in the server rooms. Additionally, not all the tools needed to perform these tasks are robust enough at this time, but many are comming along.
Allow no modules to load after a specific point in init. Establish networking and login support only after this point.
Trust nobody, lock it all down; Strip most of the capabilities from all user accounts that don't explicitly require them, including root. This includes but is not limited to running specific programs, modifying specific directories/files, and using symlinks and other handy features normally available to daemons/wheel/root accounts.
Require switching to single user mode to perform changes in the above two. (Everyone, go ahead and shout about this...it is an issue!)
Require all daemons to both be installed and run in a seperate environment similar to FreeBSD 4.0's jail() or -- potentially -- User Mode Linux when it becomes robust enough for the task. The idea is to allow an errant/hostile program to only do dammage in it's own area...and then monitor it to see if it does have problems. Killing it or reinitializing it would be fairly easy, causing minimal down time for most services.
Provide a mechanism -- such as a journaling file system or aggressive backups -- that can back out specific changes, undoing most/all of the dammage caused when it occurs.
Now, I realize that this is a colossal pain in the ass to administer, but steps like these would eliminate the need to vainly try and repair dammage to files, or to resort to backups from yesterday. The procedures/policies and scripts to make this practical or even easy still have to be created...and those aren't trivial either.
I doubt that any current OS will lack these types of features in 10 years.