SCO Unix security features (WAS Re: SCO UNIX 3.2 Failure: df Command)

[Ronald S H Khoo]

[ Brandon, skip to the last paragraph, there's something there for you ]

"Brandon S. Allbery KB8JRR/KT" <allbery at ncoast.ORG>
made some very good points about Charley Watkin's letter on SCO Unix
security which I hope Charley (with his SCO hat on) will take on board.

I personally think that the problems with SCO Unix security go far
further than Brandon's points (I think maybe he was a little too polite
:-), and it does look like SCO has a fundamental misconception about
what all the fuss is about.

I'd like Charley to respond to the net both to Brandon's points and to
a few more in addition.
(Dion, can you make sure he sees both postings ? thanks, I owe you a
beer :-)

[ >| is Charley being quoted by Brandon, > alone is Brandon ]

>| Yours is a
>| natural reaction, I think, to the ongoing adaptation of the UNIX
>| system to the needs of end-users.

> Most end-users do not need security that, even in soi-disant "relaxed" mode,
> is obtrusive.

Furthermore:

	* My customer sites *do not* have enough disc space for all that crud.

	* I don't want to have to pay royalties to SecureWare Inc
	  for "features"(+) I'm trying to turn off.

	* Many systems are NOT administered by the end-users.

	* Systems which operate as part of a much bigger system
	  (like the ones we sell: the Unix is worth 0.1% of the system)
	  often DON'T HAVE end-users in that sense.

In addition:

> Even in relaxed mode, the system screams bloody murder about authorizations
> when I attempt to add a shell to the sysadmsh menu.  Which I am trying to do
> because you've managed to make it impossible to maintain the system in any
> other way.

This kind of thing plays complete havoc with any kind of automated
maintenance scripts that people like Brandon or myself need to supply.

IMHO the mistake SCO has made with SCO Unix is to assume that it will only
be used in a narrow range of computing environments where the only way
the system is set up and maintained is "by the book" by a local sysadm who
has lots of time and little or no Unix experience.

This will leave out

	* Sites which want to move their system to a 386 PC based Unix
	  system from whatever they are currently running and have
	  enough on their hands porting the application without having
	  to replace all their administration scripts with a human and 
	  write lots of new procedures for a human to use instead of scripts.
	  They might not have time, and probably can't afford the human.

	* Turnkey systems, posssibly supplied as part of a bigger system

	* Sites which need to have uniform maintenance over a variety
	  of platforms

	* Sites which are maintained on a remote basis, with one sysadmin
	  per 50 nearly identical sites (I'm one of these -- our customers
	  DON'T HAVE sysadmins)

The first point is most galling.  It almost makes me think that this
"security package" is some kind of Trade Union ruse to keep overmanning
up.  For goodness sake, computers are meant to save labour.

> THIS I do not need.  This my company does not need.  I am close to
> recommending we switch to 386/ix, and unless there are changes we will do so.

And I would too, if not for the need to retain SCO Xenix compatibility,
which I suppose I really have to trust SCO Unix best for.
As soon as this is no longer necessary, SCO Unix will be re-evaluated with
this point strongly to the fore.  Brandon's not alone.

In other words, here are reasons you'll lose new customers, and here are
more reasons you'll lose existing customers.  This will leave you with you
lucrative US Government contracts, perhaps, but those come and go.  You should
treat that as icing on the cake, but remember that the rest of us are your
bread and butter -- not as profitable, but consistently there.  Think of the
cash flow havoc you'd have if your base level business dropped further below
your super-duper Govt contract work.

Commercial sites normally don't need soft security, we normally operate
with physical security.

> An always-active authorization database on most
> of the files in the system, however, is *not* useful under most circumstances;

And consumes resource which I (or rather the customers) can't afford.

>+---------------
>| incorporate C2 features, I think even the traditionalists among us
>| will someday have to come to grips with the presence of C2 security.
>+---------------

> Have you ever heard of an "off switch"? 

Actually, I think that'd be the wrong way round.  An "on switch" to
install it as a separate package would be far more sensible.  Even more
sensible would be to make that package unbundled.  This is the only
thing I ever want to see unbundled, by the way.  You know how two wrongs
make one right ....

You could alternatively supply all programs which access the tcb
database as partially linked objects (now that you've got the ldr
working :-) and provide libSecure.a and libNormal.a (just stubs) and let
us choose at system build time which version we want.  I don't think
many people will want the former.

> Tradition be d*mned; I'm talking about systems that *work*,

Here is another place where SCO have made a serious mis-assumption.
They seem to have assumed that "tradition" is the only concern of Unix users.
It's not simply for a veneer of "traditional" behaviour that we want to
be able to do /bin/rm -f /tcb, remember that whole Unix way of
doing things is by tying programs together in an ENVRONMENT.

If you break this environment, people who only use integrated applications
like MS-DOS users will be fine, but the rest of us will suffer (read: find
another vendor) because OUR SYSTEMS WON'T WORK ANYMORE.

You HAVE another product which is aimed at the vertical MS-DOS-type
Integrated Systems market, it's called Open DeskTop.  Can you leave the
system builder's product alone, please ?  Or possibly, sell a separate
system builder's product ?  If not, someone else will sell it.

I haven't gone out of my way to be polite here, this is too important
a subject to pussyfoot around with.  I hope you appreciate my
frankness, Charley, please don't take offence -- none is intended.

>  Assuming the !@#$%^&* authorization database doesn't throw screaming fits
>  at me, I'm going to replace the mail system with a fresh copy of mmdfIIb-43
>  from louie.udel.edu.  End of *that* problem.

You too, Brandon?  I wonder why ? :-)  Be careful -- the src/uucp/rmail.c has
incorrect arguments at update level 43, it should read

	(void) sprintf(subargs, "lvmti%s*k30*h", uchan);

(+) feature, n., documented bug (q. v.) or other failing in a supplied system.
--
UNIX is Registered TradeMark of ATT in the USA and other countries
SCO  is a TradeMark of the Santa Cruz Operation, Inc.
MS-DOS and XENIX are TradeMarks of Microsoft Inc.
Open DeskTop is a TradeMark of someone or other, it's SCO, I think.

Flames to me by email, please.  They will be summarised to the group.
-- 
Eunet: Ronald.Khoo at robobar.Co.Uk  Phone: +44 81 991 1142  Fax: +44 81 998 8343
Paper: Robobar Ltd. 22 Wadsworth Road, Perivale, Middx., UB6 7JD ENGLAND.