Path: utzoo!utgpu!watserv1!watmath!att!att!linac!pacific.mps.ohio-state.edu!zaphod.mps.ohio-state.edu!usc!apple!agate!shelby!msi.umn.edu!cs.umn.edu!quest!digibd!rhealey From: rhealey@digibd.com (Rob Healey) Newsgroups: comp.unix.sysv386 Subject: Re: SCO OpenDeskTop v1.0/Secureware HACK! Message-ID: <1990Nov28.210947.12957@digibd.com> Date: 28 Nov 90 21:09:47 GMT References: Organization: Digiboard Incorporated, St. Louis Park, MN Lines: 90 In article mju@mudos.ann-arbor.mi.us (Marc Unangst) writes: >Okay, folks, I've had it up to *here* with SCO's broken "security" >system. I think we all know that it's poorly integrated with the OS, >that it's an absolute pain in the ass, and that the first thing SCO >should do in 3.2v3 is make the stupid thing totally, completely >removable. > Amen to that. NO good reason to force this security on those of us who don't want it. Make it an optional package to purchase. >To add insult to injury, /tcb/bin/integrity says "Not authorized to >run /tcb/bin/integrity" when I'm logged in as root. Thing get >curiouser and curiouser.../tcb/bin/authck -av lists problems with >several users, including "coot" and my own login, "mju". It claims to >fix them. However, the next time I run authck, it uncovers the same >problems, and again offers to fix them. > You MIGHT have to manually tweek /tcb/files/x/xxx files to fix the problems. See below for pointers to docs. WARNING: if you don't understand what you're modifying, don't touch it! The SCO Security Boogie Man, SCO SBM, will 'git ya... B^(. >This all seems to have started when I tried to add a new group by >editing /etc/group directly, instead of going through sysadmsh. >Does anybody have any idea about what's *really* happening, and >possibly how to fix it? > THIS shouldn't matter, I've added new groups to /etc/group, removed the group map file, logged in and it all worked fine. First, throw 3.2.0 out the window and get 3.2v2.0. Don't waste any more time on 3.2.0, it's not worth your time... Try booting to single user and try fixing the problems as root. If that doesn't work, try sysadmsh as root and add all possible kernel and subsystem permissions to root. If that doesn't work, edit /tcb/files/auth/r/root file and add the needed permissions to root. If you don't know which ones to add, snoop around the ../a/auth file. Again, be careful what you modify or the SCO SBM will 'git ya. After you modify the file you'll probably have to reboot to get the changes to work. Again, try to fix the problems in single user mode. Another random tip, remember that all processes need LUID for alot of system calls, if you kill off servers they HAVE to be restarted by init or their LUID won't be correct. I've messed myself up by restarting cron and network daemons manually and thus giving them a LUID when they shouldn't have one. All this is assuming you installed with relaxed security. Also, try changing /etc/auth/system/default so that the security level is "d" rather than "c2". I don't know if that'll help but it couldn't hurt. Also remember to use sysadmsh to add users and give them "god" status; i.e. normal UNIX permissions. By the way, "relaxed" security means that /etc/auth/system/default file adds most security permissions for everyone. Nothing is REALLY "turned off" it's just that the defaults are "liberal"... u_secclass=d might let everyone operate under d security rather than c2. I have setup SCO UNIX 3.2v2.0 systems that allow all to su to root, root without a password, and all the usual UNIX freedoms. The important part is to READ, cover to cover, the 3.2v2.0 System Administrator's Guide and to use sysadmsh to do what you used to do manually by editing N+1 files. You CAN set up 3.2v2.0 so that USERS won't have any problems getting their work done. You WILL have to change how you administrate a system, you'll have to do that in the near future anyways with 5.4. You CAN set up a usable system if you take the time to learn the sysadmsh system and what's in the SA guide. If you don't have the time to do this then SCO UNIX isn't the way to go... >How about how to contact Secureware, to maybe get some docs? SCO says >that they're "proprietary"; they can't even tell me the format of a >/tcb/files/auth/x/xxx file. Security by obscurity, folks, isn't >security at all. > THAT is PURE BS on SCO's part. Check out the *.h files in /usr/include and the programmer's man pages on the auth system or tcb, it's been a while so I don't remember exactly. ALL the fields in the /tcb/files/auth/x/xxx files are fully defined and explainations of their use are given. These should be mentioned in the security section of the SA guide if you ask me... -Rob Speaking for self, NOT company.