SCO OpenDeskTop v1.0/Secureware HACK!

[Alex Win]

In article <sewJs2w163w at mudos.ann-arbor.mi.us> mju at 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 at Altos.COM)
                           Altos Computer Systems
                   2641 Orchard Pkwy, San Jose, CA  95134