lenny@icus.UUCP (Lenny Tropiano) (06/20/88)
In article <742@rush.cts.com> bob@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
lenny@icus.UUCP (Lenny Tropiano) (06/22/88)
In article <397@icus.UUCP>, lenny@icus.UUCP (Lenny Tropiano) writes: [some of my babbling left out] ... |> |> 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] |> I stand corrected by Bob Ames (bob@rush.cts.com)... He says, "It's even easier than that... just type /bin/sh<RETURN> into *ANY* office style window." -- 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