steve@unx-pc.UUCP (Stephen Hess) (04/02/91)
Hi netland, I'm thinking of removing of the ua and was wondering if there was anything I had to keep. Its taking up valuable space that I can use. I know that this will help to make my 3b1 more secure, are there any more suggestion that the net can offer me. The reason I'm asking is that several people have ask to have access to my machine so that they can learn unix and have access to the net of which was discussed about in our local paper. THANX for any input that is offer for both the removal of the ua and creating a more secure 3b1 ( if such a thing is possible ;-).-- USnail: Stephen M. Hess, 5006 Oldshire Rd, Louisville, KY 40229-1223 uucp: coplex!unx-pc!steve or steve@unx-pc.UUCP
ostroff@Oswego.EDU (Boyd Ostroff) (04/05/91)
In article <375@unx-pc.UUCP> steve@unx-pc.UUCP (Stephen Hess) writes: >I'm thinking of removing of the ua and was wondering if there was anything >I had to keep. I'm sure lots of people will disagree on this one, but here's a list of everything I removed from my 3B1. DANGER * DANGER * DANGER : I don't suggest this for the inexperienced or weak-of-heart. Don't even THINK about removing all these UNLESS you know what they are and are sure YOU don't need them. For me, I haven't missed them at all in the last two years. I run my own very simple windowing system (wlogin) on the console and do system administration the old, user-hostile, manual way. ONE MORE TIME: you'd better be pretty damn sure you know what you're doing before tying this! Basically, I just did a rm -rf on the following: usr/lib/termhelp usr/lib/ua etc/fixes etc/ph etc/wmgr etc/smgr usr/bin/300 usr/bin/300s usr/bin/4014 usr/bin/450 usr/bin/470 usr/bin/478 usr/bin/greek usr/bin/xtt usr/bin/xts usr/bin/xtd usr/bin/ua usr/bin/fsetup usr/bin/hp usr/bin/hplj usr/bin/info usr/bin/Namesys.sh usr/bin/mailsetup usr/bin/GSS.sh usr/bin/phpref usr/bin/terminal.sh usr/bin/password usr/bin/wfc usr/bin/uahelp usr/bin/uaupd usr/bin/.!. usr/bin/pwdmenu usr/bin/tutor usr/bin/Users.sh usr/bin/Ulogin usr/bin/Restore.sh usr/bin/Backup.sh usr/bin/Diagnos.sh usr/bin/Fcopy.sh usr/bin/Fformat.sh usr/bin/Fformat10.sh usr/bin/FlpyChk.sh usr/bin/Funlock.sh usr/bin/practice usr/bin/md_format usr/bin/msdos usr/bin/MsdosF.sh usr/bin/MsdosR.sh usr/bin/MsdosW.sh usr/bin/md_write usr/bin/.umodem.tmp >Its taking up valuable space that I can use. Before getting too excited, I think this was pretty drastic surgery, but it only freed up a little over 1MB on my disk.... >this will help to make my 3b1 more secure, are there any more suggestion >that the net can offer me. Get and thoroughly read the book UNIX SYSTEM SECURITY by Wood and Kochan, Hayden Books, 1985, ISBN 0-8104-6267-2. It's filled with good suggestions and (for the most part) is directly applicable to the 3B1, assuming you've gotten rid of the UA.... >THANX for any input that is offer for both the removal of the ua and >creating a more secure 3b1 ( if such a thing is possible ;-).-- Underneath its cosmetic shell, the 3B1 is just another System V Unix box. Within those limitations, there's no reason it shouldn't be possible. |||| Boyd Ostroff / Tech Director / SUNY Oswego Dept of Theatre / 315-341-2987 |||| SysAdm at cboard.UUCP / Serving the Performing Arts / 315-947-6414/8N1 |||| ostroff@oswego.oswego.edu / cboard!ostroff@natasha.oswego.edu
jon@jonlab.UUCP (Jon H. LaBadie) (04/08/91)
The recent discussion of security on the 3B1 (is that an oxymoron?) caused me to recall that I've never seen this particular hole posted. There is a function in the TAM library, eprintf(3T), that is used to print error messages. It is how the ! and !! icons get on the first line of your screen. Also, the calendar icon if you are using the pcal program. I believe eprintf writes to /dev/error, which is read by smgr. It all seems pretty innocuous, display an icon, print a message when a user clicks on the icon. No danger there. EXCEPT, one of the arguments to eprintf(3T) is what to do when the user clicks on the icon. And one of the possibilities is ST_EXEC; execute a program!!! Guess which user id, and in which directory the program is executed; You security hounds are right: by root and in the root directory. So, essentially, anyone with access to your C compiler has access to your entire machine! Sleep comfortably last night? Jon
emm@iczer-1.UUCP (Edward M. Markowski) (04/09/91)
In article <927@jonlab.UUCP> jon@jonlab.UUCP (Jon H. LaBadie) writes: |Guess which user id, and in which directory the program is executed; | |You security hounds are right: by root and in the root directory. | |So, essentially, anyone with access to your C compiler has access to |your entire machine! This is only a problem if the user also has access to the console. You might be able to close this hole by securing(sp?) /dev/error, I don't think joe user does really needs access to /dev/error. -- ------------------------------------------------------------------------------- Edward M. Markowski -- iczer-1 Administrator ...the garage is flooded from the sprinkler. VOICE : (201) 478-6052 It also left a man's decapitated body, lying UUCP : ..!uunet!iczer-1!emm on the floor next to his own severed head. -or- : ..!tronsbox!iczer-1!emm A head which at this time has no name.
dt@yenta.alb.nm.us (David B. Thomas) (04/10/91)
jon@jonlab.UUCP (Jon H. LaBadie) writes: >EXCEPT, one of the arguments to eprintf(3T) is what to do when the >user clicks on the icon. And one of the possibilities is ST_EXEC; >execute a program!!! >Guess which user id, and in which directory the program is executed; >You security hounds are right: by root and in the root directory. Actually, with the stock /etc/rc script, the current directory is /etc/lddrv when /etc/smgr is started. smgr is the program that reads /dev/error and puts up the icon, and it is to blame for the hole. Lenny Tropiano was aware of this hole in a slightly different form: if smgr puts up an envelope, indicating you have mail, and you click on the icon, it starts up /bin/main, as root, with /etc/lddrv as the current directory. Imagine my confusion when, after typing "s" to save a mail message, it wasn't in my home directory, but instead was eventually found, owned by root, in /etc/lddrv!! Anyway, Lenny's solution was to write his own email program, which takes care of the permissions and stuff. It's called email<something>, and it's in osu-cis. >So, essentially, anyone with access to your C compiler has access to >your entire machine! As someone else already pointed out, they have to get at the console to exploit this hole, and anyone with access to your console can boot it from a floppy and do anything they want!! I don't use smgr anyway. It's handy, but now that I have mgr, I can cheerfully say goodbye to wind.o and everything associated with it. Hmmm.... anybody know if I can remove the tam stuff from the shared library. Since I don't load the window driver I can't possibly use it. By the way, my mgr hacks are coming along. Soon, I expect to release some diffs so it blanks automatically after a period of time, and I'm working on some faster bit blits in assembler. This baby oughta scream! little david -- Robert Thomas, speaking of good software for Unix vs. MsDos: "Quality is either the result of a whole lot of dedication, or it's a thin layer of cream on top of a whole lot of milk."
jon@jonlab.UUCP (Jon H. LaBadie) (04/10/91)
In article <584@iczer-1.UUCP>, emm@iczer-1.UUCP (Edward M. Markowski) writes: > In article <927@jonlab.UUCP> jon@jonlab.UUCP I, Jon H. LaBadie wrote: > |Guess which user id, and in which directory the program is executed; > | > |You security hounds are right: by root and in the root directory. > | > |So, essentially, anyone with access to your C compiler has access to > |your entire machine! Ed replied: > This is only a problem if the user also has access to the console. Well, then again, I could schedule a trojan horse to run when YOU, who does have access to the console clicks on the icon. In fact, with one of the other parameters to eprintf(3T), I can specify who sees the icon. I think this widens the problem to anyone with access to the system. > You might be able to close this hole by securing(sp?) /dev/error, > I don't think joe user does really needs access to /dev/error. You may be correct. However, the designers of the safari 4 seemed to expect that the device would be widely available. Thus, mail and pcal can get their icons up on the status line. Other equally non-privledged programs can also get messages there. Break the chain, and you may enhance security, but you may also degrade useability of the system. Boy, isn't that the general trade-off? Jon -- Jon LaBadie {att, princeton, bcr, attmail!auxnj}!jonlab!jon
vince@tc.fluke.COM (Craig Johnson) (04/11/91)
dt@yenta.alb.nm.us (David B. Thomas) writes: > As someone else already pointed out, they have to get at the console to > exploit this hole, and anyone with access to your console can boot it from > a floppy and do anything they want!! Following up on an idea posed several weeks ago, I've been thinking about generating my own boot ROM with some new features added. For example, how'd you like the ability to run diagnostics by typing a secret command at boot up time without having to find and load the diagnostic disk? After a few seconds the boot would proceed normally if no command were entered. Another thought was to include a secret command to allow booting from the floppy, thereby preventing anonymous users from booting off it. Of course the drawback is that you need to reprogram the boot ROMs if you want to change the secret commands and/or passwords and/or update the diagnostics. But if you need real security, then maybe that's OK. What do you think? I'm not faced with a security problem and don't need to have floppy boot protection for myself, but if I were encouraged by enough feedback I'd consider doing it for others. If anyone else is interested in pursuing this, note that the boot ROM utilizes only about 4K of 32K available (with 27128's used; 2764's or 27128's can be used) in a 4M address space reserved solely for the ROM. s4diag won't fit in the present ROMs but with the addition of 2 more address lines and changing to 27512's it will. It should be a quick and easy hardware hack since the 27512 pinout is nearly the same (28-pin) as the 27128. I figure I'll still need to strip the .bss section from s4diag to get it to fit. Other than that, I was going to copy s4diag without change to the ROM. At run time, I was going to simply copy s4diag to RAM in the same location that the loader normally would do if it were read in from a floppy and transfer control there. I will check to see if the loader changes anything in the MMU mapping and make sure proper initializations are performed if needed prior to transferring control. Of course, we could consider putting other things in the boot ROM. Can you say "diskless node"? Hmmm. I'll leave that to your imagination. --- Craig V. Johnson ...!fluke!vince John Fluke Mfg. Co. or Everett, WA vince@tc.fluke.com
clewis@ferret.ocunix.on.ca (Chris Lewis) (04/12/91)
In article <927@jonlab.UUCP> jon@jonlab.UUCP (Jon H. LaBadie) writes: >The recent discussion of security on the 3B1 (is that an oxymoron?) >caused me to recall that I've never seen this particular hole posted. It's worse than that - if you send mail to the root user, the user on the console can break into root using the mail icon.... No compiler neccessary. Ugh. -- Chris Lewis, Phone: (613) 832-0541, Internet: clewis@ferret.ocunix.on.ca UUCP: uunet!mitel!cunews!latour!ecicrl!clewis; Ferret Mailing List: ferret-request@eci386; Psroff (not Adobe Transcript) enquiries: psroff-request@eci386 or Canada 416-832-0541. Psroff 3.0 in c.s.u soon!
yarvin-norman@cs.yale.edu (Norman Yarvin) (04/12/91)
>You might be able to close this hole by securing(sp?) /dev/error,
The security hole is caused by smgr, which reads /dev/error and puts up the
icon. It can't be closed by not running smgr as root, since smgr needs to
run as root to perform the functions of cron. It can be closed by not
running smgr, and instead running Mike Ditto's 'errdemon', which reads
/dev/error and writes entries to a log file.
--
Norman Yarvin yarvin-norman@cs.yale.edujohn@chance.UUCP (John R. MacMillan) (04/12/91)
|There is a function in the TAM library, eprintf(3T), that is used to |print error messages. It is how the ! and !! icons get on the first |line of your screen. Also, the calendar icon if you are using the |pcal program. | |I believe eprintf writes to /dev/error, which is read by smgr. | |It all seems pretty innocuous, display an icon, print a message when |a user clicks on the icon. No danger there. | |EXCEPT, one of the arguments to eprintf(3T) is what to do when the |user clicks on the icon. And one of the possibilities is ST_EXEC; |execute a program!!! | |Guess which user id, and in which directory the program is executed; | |You security hounds are right: by root and in the root directory. Tom Kelly <tom@ancilla> pointed this out at one time. I think he also ST_LOG was a problem, since you can use it to write any file (eg. /etc/passwd), as root. Very scary, and just another reason to not run smgr. (I don't; I use mgr.) |So, essentially, anyone with access to your C compiler has access to |your entire machine! Who needs a C compiler? Try: echo ":D:E::/usr/bin/id\c" > /dev/error |Sleep comfortably last night? I slept just fine...