SCO OpenDeskTop v1.0/Secureware HACK!

[Rob Healey]

In article <sewJs2w163w at mudos.ann-arbor.mi.us> mju at 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.