Security Issues on the 3B1 *LONG* (was Re: Help needed with 7300)

[Lenny Tropiano]

In article <742 at rush.cts.com> bob at rush.cts.com (Bob Ames) writes:
|>Sorry, on the UNIX PC 7300/3B1, knowing the root password only allows
|>me to get to Super-User about 30 seconds sooner that without the root
|>password.  This system has many security holes in it.  This was
|>discussed some time back on the net. Does anyone have the archives
|>on that discussion?  Specifically, have the attempts at removing/
|>changing uasig and uaupd been successful?  What about the other holes?
|>
|>Has anyone succeeded in providing an Office to someone and still manage to
|>prevent access to Super-User?  I can become SU within 1 minute of getting
|>to *ANY* office on all unix-pcs that I know of.
|>

It takes you that long? ;-)   Yes, the UNIX pc is riddled with security
flaws... most of the can be easily patched up.  The first time I posted
this I got a few *FLAMES* but I believe the people who own these machines
have a right to know where to look, and patch up the holes that exist
in their systems [most of which are open to users who are unauthorized
to be the superuser].

I probably don't have the "all complete list security flaws on the UNIX pc"
but this is a quick summary [from memory] of the things I can think of
right away:

1.	The UA [user agent] is a big security headache.  If you allow
	users to use this they can become root quite simply.  UA doesn't
	run s-uid, but /usr/lib/ua/uasig and /usr/lib/ua/uasetx do. In
	the manual pages for ua(4) the EXEC action has the "-p" option
	which basically says:

		"-p	Run the process with superuser privileges"

	A user can make a file in their HOME directory called "Office"
	and make something like:

			Name=Superuser UNIX Shell
			Default = Run
			Run=EXEC -dpw $SHELL
			Prompt = Press Ctrl-D to exit

	And then they will have root access when they select their
	new object "Superuser UNIX Shell".

	[Best solution:	disallow access to the UA for non-trustworthy
			users.  Make a subsystem filesystem and then
			chroot(1M) to it and put a limited amount of
			commands to make the system very restricted.]

	[Fair Solution:	make a special group and only allow access to UA
			programs for that group (ie. mode 750 - don't allow
			world executable access)]

2.	EXPERT syntax for the user agent has wholes.  Login's like "tutor"
	can very easily get a "shell" by creating a file in the Filecabinet
	and then doing a shell-escape from "vi" with ":shell".  

	[Best solution:	remove tutor login and don't rely on EXPERT]

	[Fair Solution: put a password on tutor]

3.	Mail Setup from Adminstration windows allow login and dialup
	information to be seen by any user (not just login "install").

	[Best solution: do use the UA and disallow access (see #1)]

	[Fair solution: replace /usr/bin/mailsetup with a shell script
			echoing appropriate authorization failure to access
			/usr/lib/uucp/L.sys (already done with HDB 
			installation]

4.	Permissions of files when installing Foundation Set and other
	utilities are very bad.  Most of them are world-writable, which
	allows users to just clear them out with:

	$ > file-to-clear
	-or-
	$ cp /dev/null file-to-clear

	Most important one to fix is the root "/" directory which is
	currently 777 on 3.51 (and other) releases of the operating system.
	755 or 775 will do just fine.

	[Only solution:	get a master list of all the world-writable files
			and change the files one-by-one until you get
			your desired security.  Some particular ones to
			look for are in /etc/lddrv/* (your device drivers)
			and system programs in /bin and /usr/bin]

	Find those files with:

	# find / -perm -2 -print | xargs ls -ld | more

5.	The setuid programs should be checked (s-bit'd programs are
	always places for security flaws).

	# find / -perm -4001 -user root -print | xargs ls -ld | more

	Change the program /etc/lddrv/lddrv to 755 as only "root" should
	be every allocating (deallocating) and binding system drivers.
	If a user can allocate a driver, he/she chould write a device
	driver to do nasty stuff at the low-level hardware access...
	[yeech... this sends chills up my spine]

6.	Mail Icon from the System Manager (smgr) program will exec 
	/bin/mail, but a simple "!" from inside mail will get you to
	a root shell.

	[Best solution: get the email.c program that I wrote and posted
			a while back that allows you to run with the mail
			icon safely.  It also fixes things like mail being
			saved in /etc/lddrv directory and allows you to
			exec your favorite mailer (eg. mailx, elm, etc..)]

	[Fair solution: disallow the mail icon by creating a shell script
			called /usr/bin/email that has a "exit 1" in it]


There are probably other problems, but these are the MAJOR ones that come
to my mind when you say "Security on the UNIX pc".

Let me know if you think of others...

-Lenny



-- 
US MAIL  : Lenny Tropiano, ICUS Software Systems      IIIII  CCC U   U  SSS
           PO Box 1                                     I   C    U   U S
           Islip Terrace, New York  11752               I   C    U   U  SS 
PHONE    : (516) 968-8576 [H] (516) 582-5525 [W]        I   C    U   U    S
TELEX    : 154232428 [ICUS]                           IIIII  CCC  UUU  SSS 
AT&T MAIL: ...attmail!icus!lenny  
UUCP     : ...{talcott, boulder, pacbell, sbcs, mtune, bc-cis}!icus!lenny