mju@mudos.ann-arbor.mi.us (Marc Unangst) (11/13/90)
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. However, that's not what my problem is. My problem is this: The system is broken, and I can't figure out how to fix it. When I boot up multi-user, cron(8) aborts with "cron: can't find group cron". If I try to su(1) from a non-root account, it tells me that create_file_securely() exited with status 2. I can only log on as root on tty01, and the system says "Security database corrupt. However, root login on tty01 is allowed." If I try to log on as a normal user or on a different terminal, it says "Can't rewrite Terminal Control Database entry. See Authentiation Administator." (Incidentally, /bin/login seems to have the name "root" hardcoded into it -- I have a csh root called "coot", and I can't log in as coot on the console. UID 0, GID 0, home directory /. I guess this is another incompatibility -- superuser privileges are UID and GID 0, not having the login-id "root". It's a good thing I didn't rename "root" something like "god", or I'd *really* be in trouble.) When I log in as root in single-user mode, it appears that /etc/auth/system/gr_id_map isn't getting created like it should be. 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. This all seems to have started when I tried to add a new group by editing /etc/group directly, instead of going through sysadmsh. However, I've removed that group (and all users that were in it), and things are still broken. I've talked to SCO technical support, and they're completely stumped. (I have an appointment to talk to a "senior technical analyst" tomorrow, but I'm not exactly in the most optimistic of moods about it.) Quite frankly, I'm getting sick and tired of ODT's stupid security system, and if I didn't have to support my customers who are running ODT, I'd trash it and get REAL SysVr3.2. Does anybody have any idea about what's *really* happening, and possibly how to fix it? 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. -- Marc Unangst | mju@mudos.ann-arbor.mi.us | "Bus error: passengers dumped" ...!umich!leebai!mudos!mju |
dsmythe@netcom.UUCP (Dave Smythe) (11/15/90)
I've found that the easiest (!) way of deterministically discovering what is going on is to run find and save the output, make your change via sysadmsh, run find again, then diff the output to see what changed. The format of /tcb/files/auth/z/zzz is termcap-format, I believe, and I remember seeing the field descriptions somewhere; probably either the ADMIN *Reference* (not the *guide*) or maybe the system include files. The whole thing's pretty annoying, if you ask me... Ever since I found out that if you are running as suid root and the files you create (from a shell at least) aren't root-owned, I've been suspicious of everything. Hope they finish GNU soon... D -- Dave Smythe netcom!dsmythe@apple.com N6XLP (also dsmythe@portia.stanford.edu)
alex@altos86.Altos.COM (Alex Win) (11/16/90)
In article <sewJs2w163w@mudos.ann-arbor.mi.us> mju@mudos.ann-arbor.mi.us (Marc Unangst) writes: >... >I can only log on as >root on tty01, and the system says "Security database corrupt. >However, root login on tty01 is allowed." If I try to log on as a >normal user or on a different terminal, it says "Can't rewrite >Terminal Control Database entry. See Authentiation Administator." It appears that you may either have a lock file lying around or your "Terminal Control Database" file is corrupt. Go into single-user mode and see if "ttys-t" or "ttys-o" is present in /etc/auth/system. If so, remove it -- the file prevents users from updating the Terminal Control Database when logging in. If the lock files are not there, your Terminal Control Database may be corrupted. Move your /etc/auth/system/ttys file to a temp file, create an empty ttys file in /etc/auth/system, and run '/tcb/bin/ttys_update'. This will recreate your Terminal Control Database from your init.base file in your /etc/conf/cf.d directory. >(Incidentally, /bin/login seems to have the name "root" hardcoded into >it -- I have a csh root called "coot", and I can't log in as coot on >the console. UID 0, GID 0, home directory /. You're right. If login fails on non-console ports, your last ditch option is to login on /dev/tty01 (or /dev/console) as 'root'. You'll probably encounter problems with setuid commands (like /tcb/bin/integrity) since the login did not go through normal means. I would think single-user login might give you better luck. >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. I've never seen 'authck' work. >... >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. > From the look of it, I don't believe the problem is with the /tcb/files/auth/... files. But if you need to know, read the Security chapter in the System Administrator's Guide and you can pretty much correlate it to the fields in the xxx files. If not, having the source to the SecureWare library helps :-) -- Alex Win (alex@Altos.COM) Altos Computer Systems 2641 Orchard Pkwy, San Jose, CA 95134
em@dce.ie (Eamonn McManus) (11/16/90)
dsmythe@netcom.UUCP (Dave Smythe) writes: >The format of >/tcb/files/auth/z/zzz is termcap-format, I believe, and I remember seeing >the field descriptions somewhere; probably either the ADMIN *Reference* (not >the *guide*) or maybe the system include files. There is some information available from `man authcap', though it is rather sketchy. >The whole thing's pretty annoying, if you ask me... I'll say. -- Eamonn McManus <em@dce.ie>
rhealey@digibd.com (Rob Healey) (11/29/90)
In article <sewJs2w163w@mudos.ann-arbor.mi.us> 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.