ESIX and MCA

[Piercarlo Grandi]

On 17 Nov 90 04:29:28 GMT, jca at pnet01.cts.com (John C. Archambeau) said:

jca> One of the things I have done is rule out getting ESIX for the
jca> system that I'm proposing in the next few months.  Reason being
jca> that security hole that was mentioned awhile back.  Since the
jca> machine in question will be used as a mailhost and gateway, it
jca> would be very foolish to use an OS with even the HINT of a security
jca> hole.

So right! You remind me of what somebody else says, that the only way to
make a computer secure is to place the power switch in the OFF position.

But of course you are being intentionally amusing here -- what you write
above either demonstrates either a jocular attitude or complete
misunderstanding of the problems of mailhost and gateway security, and I
cannot believe the latter option.

If you were not joking, your statement above would be a classic example
of the well known principle that the greatest security hazard is a false
sense of security, and the worst possible false sense of security is
thinking that security is more of a tools than of a people problem.

For example, by way of not mentioning it, you are surely obliquely
making fun of SCO Unix, a system whose security system is so complex and
obnoxius that most people disable it in haphazard ways by default,
possibly leaving themselves less protected than if it were not there to
be bypassed!

    Note that in the hands of a system administrator with a sure grasp
    of security theory and practice, and a lot of patience and self
    discipline, as it is obvious you really are, SCO Unix C2 security
    is a tool that can indeed provide substantial added protection.

You are also probably making also fun of all those system administrators
that still use sendmail (whether or not the DEBUG option is compiled in
by default) instead of smail3, which is far simpler to configure and
thus probably more reliable, not to mention that you have sources and
can apply corrections instantaneously (the same advantage of course
applies to the freely available UCB sendmail, but here you feign
ignorance of its availability, and pretend you have to stick with the
manufacturer's binary, over which you have no control).

jca> Sorry Everex, but if you had a better attitude about fixing things
jca> that were broken, then I would reconsider.  Now I'm looking at SCO,
jca> ISC, Dell, Intel, and UHC.

Hahahaha. Even better! You are a good sport. Here you must be making fun
at some of these other vendors; probably you are thinking of how much
time (months, years!) after patches were posted in this newgroups did
any of these release a version of the filesystem that did not have the
inode allocation bug. Also, your reference at UHC means that you are
pretending to consider SVR4, which is just out, and therefore presumably
a poor choice if one wants a stable and well debugged system for
reliability and security.

I must confess that this way of poking fun at manufacturers and this
audience pretending you are naive and do not understand the issues is
very amusing. But of course you give away the whole show in the
signature:

jca> ... | Small memory model only for
jca> ... | Unix?  Get the (*bleep*) out
jca> ... | of here!

Here you surpass yourself in subtlety: your irony here is that *all*
UNIXes on 386 allow you to run programs _only in the small memory model_
(even if the UNIX kernel actually runs in the large memory model, in a
small way :->).

Here your sarcasm is based on pretending that you don't know that the
small memory model on the 386 has 32 bit offsets and the large one 48
bit pointers, instead of 16 and 32 bits as on the 286!

    As far as I know only Intel's iRMX allows you to run large memory
    model (segmented, 48 bit pointers) programs on the 386.
--
Piercarlo Grandi                   | ARPA: pcg%uk.ac.aber.cs at nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth        | UUCP: ...!mcsun!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg at cs.aber.ac.uk