annala@neuro.usc.edu (A J Annala) (12/28/90)
In article <277916E3.2042@tct.uucp> chip@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? Thanks, AJ p.s. The source microfiche for VMS is mostly BLISS, MACRO assembler code generated from BLISS, some FORTRAN, and a few rare PASCAL programs. However, I will back away from arguing DEC could have converted VMS for use in the 386 environment because there are many more machine dependencies in the source code than I originally realized. Still, it is curious DEC adopted SCO UNIX/386 MPX for it's 386 platforms.
ronald@robobar.co.uk (Ronald S H Khoo) (12/29/90)
annala@neuro.usc.edu (A J Annala) writes: > In article <277916E3.2042@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes: > Could someone describe exactly what sysadmsh-->system-->relax actually does > and what more it should do to disable C2 security for software developers? I'd appreciate a definitive answer to this question too. One thing it does do is to use default.unix instead of default.c2 as default in /etc/auth/system. I use neither -- I think I added some extra default permissions to mine -- those of you who read the script I use to process /etc/passwd would have noticed that I don't put explicit permissions in /tcb/files/auth/?/* but just set the default to include the permissions I want since it's a lot easier to maintain things that way -- in case SecureWare decide to increase the number of explicit permissions needed at some future downgrade, I can just adjust it in one place. Actually, I hope by then I'd have another UNIX. Does anyone know if u_secclass does anything in the current SCO releases ? I remember someone saying that making it "d" and rebooting made a difference to them (was it Brandon?) but I can't seem to find any difference. Happy New Year to one and all. Even the guys at SecureWare. Yeah, why not. -- ronald@robobar.co.uk +44 81 991 1142 (O) +44 71 229 7741 (H)
allbery@NCoast.ORG (Brandon S. Allbery KB8JRR) (12/29/90)
As quoted from <29044@usc> by annala@neuro.usc.edu (A J Annala): +--------------- | In article <277916E3.2042@tct.uucp> chip@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@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
allbery@NCoast.ORG (Brandon S. Allbery KB8JRR) (12/30/90)
As quoted from <1990Dec29.005544.6641@robobar.co.uk> by ronald@robobar.co.uk (Ronald S H Khoo): +--------------- | Does anyone know if u_secclass does anything in the current SCO releases ? | I remember someone saying that making it "d" and rebooting made a difference | to them (was it Brandon?) but I can't seem to find any difference. +--------------- u_secclass=d disables checking of the secure files database (which otherwise causes major complaints if you ever dare to change things without updating the file lists to match; it screams bloody murder about security violations). I had hoped it would also disable luid's, but it doesn't. ++Brandon -- Me: Brandon S. Allbery VHF/UHF: KB8JRR on 220, 2m, 440 Internet: allbery@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