SCO UNIX C2 Security Issues (Re: Why DEC chose SCO UNIX)

[Brandon S. Allbery KB8JRR]

As quoted from <29044 at usc> by annala at neuro.usc.edu (A J Annala):
+---------------
| In article <277916E3.2042 at tct.uucp> chip at tct.uucp (Chip Salzenberg) writes:
| >3.  The C2 security (as described in #2) can be "relaxed", but not
| >    disabled.  That is, the default kernel permissions can be broadened
| >    from their fascist defaults, but the kernel is still a C2 kernel.
| >    So the administrative headaches are still there.
| 
| Could someone describe exactly what sysadmsh-->system-->relax actually does
| and what more it should do to disable C2 security for software developers?
+---------------

"Relaxed" security basically sets C2 parameters to their most permissive.
Terminals don't lock up after a set number of login failures (this wreaks
havoc when trial-and-error'ing a bidirectional modem cable, as long experience
has taught me never to trust anyone's RS-232C pinouts).  Accounts don't lock
out after a set number of login failures.  The subsystem authorizations are
defaulted to that of regular of SVR3.2.

What relaxed security does *not* do is disable luid's, which means that
setuid() fails unless the luid is set and someone with an luid other than 0
can su only to root (if s/he knows the password) or to any account for which
his/her luid is defined as the "owner" --- you can not have more than one
account owning another, and (to answer a suggestion made last time I commented
on this) changing u_secclass to "d" in /tcb/auth/system/default (or whatever
it is --- I'm at home right now and I guarantee you SCO's current C2 security
will never be permitted here) does *not* disable this.

It also does not change the fact that the system state (information on users,
devices, etc.) that are stored in standard places in System V are scattered
under multiple places in /tcb/foo/bar/huh/glortz/??? (you get the idea) under
SCO "Unix".  I have to maintain a wide variety of systems at work --- the
SunOS/SVR4 directory scheme was one h*ck of a lot easier to cope with in our
portable utilities than the SCO "Unix" mess.  (I have stuff that runs under
Altos System V, Xenix, and the DG AViiON, but needs to be massively rewritten
to work under SCO "Unix".  I refuse, since the result will not be portable.)

+---------------
|       it is curious DEC adopted SCO UNIX/386 MPX for it's 386 platforms.
+---------------

No, it isn't.  DEC's been selling Tandy machines with DOS and probably Xenix
available for a couple of years now.  And they aren't really interested in the
market, so they went with something that was available and had a large amount
of software available for it (anything that runs under Xenix, as long as it
doesn't run afoul of that same anti-portability (read: security) system).

++Brandon
-- 
Me: Brandon S. Allbery			    VHF/UHF: KB8JRR on 220, 2m, 440
Internet: allbery at NCoast.ORG		    Packet: KB8JRR @ WA8BXN
America OnLine: KB8JRR			    AMPR: KB8JRR.AmPR.ORG [44.70.4.88]
uunet!usenet.ins.cwru.edu!ncoast!allbery    Delphi: ALLBERY