on Thu, Nov 22, 2001 at 02:12:17AM -0800, Petro (petro@auctionwatch.com) wrote:
> On Wed, Nov 21, 2001 at 11:04:32PM -0800, Karsten M. Self wrote:
> > on Tue, Nov 20, 2001 at 01:38:11PM -0800, Mark Ferlatte
> > (ferlatte@cryptio.net) wrote:
> > My own experience running GNU/Linux and OpenBSD (2.7) side-by-side is
> > that I get the odd freeze and restart on oBSD, but not GNU/Linux (unless
> > it's something I've done myself, usually involving crashing X). Typical
> > uptimes on both systems run months. UPS on the GNU/Linux box, I've
> > watched the oBSD walk straight through power flux that flickers the
> > lights, with nothing more than a surge protector.
>
> Not to slam oBSD, as it's really good at what it aims to be, but
> it's a niche product aimed at a specific target, and it's really
> good at that. "Heavy Lifting" isn't that target.
Depends on the heavy lifting involved. For a wide range of
public-facing network services, it's perfectly acceptable.
> Oh, and walking through that flicker? That was your power supply,
Actually, I checked -- it's a power strip, not a surge protector. I
think it's the heavy electrons, they take longer to slow down ;-)
> > OpenBSD offers a very tight, very secure, by default, system. What you
> > lose in the process are:
> >
> > - Flexibility of configuration and modification. I like SysV init.
> > Theo rants how it sucks and is more complex. The Debian
> > implementation is damned good for GNU/Linux, is worlds better than
> > Red Hat's "gee, we could use another three levels of indirection,
> > let's put them in" crap, and makes starting, stopping, and
> > restarting services completely straightforward.
>
> Uh, not to be an argumentative drunk, but what about
> /etc/alternatives?
I don't think that's terribly complex. It's not much more than is
already done in /lib and /usr/lib to point to the proper libraries.
Symlinks.
My contact with RH boxen is pretty limited these days, but I know
there's a bunch of cruft under /etc/sysconfig for networking that's
sourced in multiple places. I've had headaches trying to work out what
goes where with RH's MySQL startup scripts. I find that the /etc/init.d
(or /etc/rc.d/init.d) script frequently invokes at least one level, and
sometimes two or more, of other scripts. Tracing execution through this
path is tortured. Debian does far better at localizing everything to
the /etc/init.d script itself, or, where it doesn't, to localizing the
additional cruft to a minimal number of locations
(/etc/network/interfaces).
> > oBSD is pretty clear that it's a full *system*, not merely an
> > assembly of packages as is the case for many GNU/Linux distros
> > (Debian included). However, the collection of packages approach
> > means that Debian can offer many things to many people. oBSD is
> > pretty much "secure Unix clone, primary network services
> > orientation". Not a bad thing. But limited choice.
>
> Every network, every sub-net, every cluster has different
> requirements. Debian/Linux offers a much wider variety than BSD. Not
> that this is always a good thing, but it allows you to customize for
> your own needs.
Agreed.
> > Bruce Schneier identifies four periods of concern for security
> > issues:
> > 1. Introduction of vulnerability. It exists, but is unknown.
> > 2. Awareness. It is known, but not necessarially patched.
> > 3. Introduction of fix. A software patch is available.
> > 4. Application of fix. Software patch is widely applied.
>
> Number 4 is wishful thinking.
It's a numbers game. Debian makes accomplishing # 4 far easier than any
other system I'm familiar with.
> > What oBSD does is try to minimize factor 1. What Debian does is
> > address 3 & 4. They're somewhat orthogonal approaches (Debian also
> > addresses 1 a bit), but both have significant impacts on the
> > security of *your* system. I find the Debian approach to be more
> > compelling.
>
> Quite frankly, proper design and coding is the only way to prevent
> most vulnerabilities.
>
> Everything else is locking the barn door when you're not sure the
> horse is still inside or not. Yes, you still have to lock the door,
> but it's occasionally too late.
Making sure the barn door's made of wood (or steel) rather than paper
helps.
OpenBSD's audit focusses very heavily on eliminating buffer overflows
and looking at use of UID 0. Between the two of these, you're attacking
the foundations of a large number of possible exploits. The other
attack angle is sane configuration defaults. Since the majority of
users never touch the defaults, and a large number of exploits are based
on buffer attacks, this actually cuts the vulnerability profile
significantly. Debian could learn from this, and is, with the various
hardened packages / tasks which can be applied.
> The web-based scheduling/calendaring pretty much sucks unless you're
> willing to spend money on it. But this is going to be true for any
> platform.
Yeah, I guess the word with calendaring that it all sucks, and mostly
doesn't exist.
Incidentally, there was an item about HP's OpenMail package, an Exchange
replacement, IIRC. This is a product HP's indicated it's going to
shelve, I'm not sure if the announcement is saying that the product will
be continued, or just that there's some near-term development happening:
http://eltoday.com/article.php3?ltsn=2001-11-16-001-14-PS
...reads as if it's the latter. Pity.
OpenMail's one of HP's worse failings. The company really ought to
pick up the product and run with it, free software if at all possible,
and put the squeeze on MSFT.
Peace.
--
Karsten M. Self <kmself@ix.netcom.com> http://kmself.home.netcom.com/
What part of "Gestalt" don't you understand? Home of the brave
http://gestalt-system.sourceforge.net/ Land of the free
Free Dmitry! Boycott Adobe! Repeal the DMCA! http://www.freesklyarov.org
Geek for Hire http://kmself.home.netcom.com/resume.html
Attachment:
pgpunPG51Y0Zz.pgp
Description: PGP signature