Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!apple!mauxci!eci386!ecicrl!clewis From: clewis@ferret.ocunix.on.ca (Chris Lewis) Newsgroups: comp.sys.3b1 Subject: Re: COPS security audit and the unix pc. Message-ID: <1991Mar26.225255.6048@ferret.ocunix.on.ca> Date: 26 Mar 91 22:52:55 GMT References: <1991Mar23.004007.2024@shibaya.lonestar.org> Organization: Elegant Communications Inc, Ottawa, Canada Lines: 110 In article <1991Mar23.004007.2024@shibaya.lonestar.org> afc@shibaya.lonestar.org (Augustine Cano) writes: >When I first ran the COPS security package on my 3b1, I got a report more >than 250 lines long. Most of the entries were about files and directories >being world-writable. As you've discovered, the 3b1 is particularly bad w.r.t. security. The problem is threefold: - "vanilla" installations have lots of world-writable stuff. Eg: /, /usr and /etc. - Some of the cleanup and "ordinary" operation scripts will re-clobber the permissions. Eg: /etc/inittab and /etc/wtmp. - Some programs simply have big holes in them (ie, given access to the console and the mouse, it's easy to break into root) >chmod o-w ... /usr/spool/news Unless you're using C-news, you just broke your news system. Aha, you ARE using C-news (/usr/lib/newsbin). Consider this a warning to anybody else reading this article - if you're running B-news, do NOT make /usr/spool/news or /usr/lib/news anything other than 777. Sigh... >chmod o-w /. /.. COPS is busted. >One directory that CANNOT be treated in this manner is /usr/spool/uucp. >I tried it and kermit couldn't then set or clear locks. >> Warning! Root does not own the following file(s): >> found found found /bin >Is this of any consequence? No. C-news, for example, *expects* it to be bin (in order to run "doit.bin"). This is a matter of taste. >> Warning! /usr/spool/uucp is _World_ writable! >This one has to be ignored; as I said above certain programs might not be >able to access locks if this is changed. The real solution is to fix Kermit. Or use HDB (where the lock directory can be made world writable but not everything else) >> Warning! /etc/drvtab is _World_ writable! >> Warning! /etc/inittab is _World_ writable! >> Warning! /etc/wtmp is _World_ writable! >Does anybody know if this has to be so? (particularly for /etc/wtmp). Particularly "/etc/inittab" - this is the most vital file in your machine. (well, aside from /unix and one or two others). A single misplaced character in /etc/inittab can hang your machine requiring a floppy boot. inittab should be 644 or 444, but the admin scripts occasionally zap it back to 666. You should put a chmod in your crontab. Ditto wtmp. drvtab appears to be something built during the boot process, probably doesn't matter much. >> Warning! /usr/adm/NBS.log is _World_ writable! >> Warning! /usr/adm/UNIX.log is _World_ writable! >> Warning! /usr/adm/cronlog is _World_ writable! >> Warning! /usr/adm/drv.log is _World_ writable! >> Warning! /usr/adm/sulog is _World_ writable! >> Warning! /usr/adm/unix.log is _World_ writable! >Log files... the security risk coming from here is, even in the worst case, >minimal. Matter of opinion I guess, but it makes it more difficult to trace breakins if you make it easy for a cracker to clobber them. I don't know about NBS.log, but all of the others can be made 644. >> Warning! /usr/lib/crontab is _World_ readable! >> Warning! /usr/adm/sulog is _World_ readable! >Should anybody care about these two? COPS output is looking more and more >like lint... Depends on how paranoid you are. >> Warning! File /dev/console (in /etc/rc*) is _World_ writable! >> Warning! File /dev/window (in /etc/rc*) is _World_ writable! >> Warning! File /usr/lib/ua/.blanktime (in /etc/rc*) is _World_ writable! >> Warning! User uucp's home directory /usr/spool/uucppublic is mode 0777! >> Warning! User nuucp's home directory /usr/spool/uucppublic is mode 0777! >Of course, since all uucp accounts have the same home directory, the >same message appeared once for each uucp-connected machine. You can fix .blanktime without worrying about it. I contend that if COPS is complaining about uucp userid logins, it's busted. >> Warning! /usr/lbin/uudecode creates setuid files! >This, according to the documentation, is pretty common, but without >re-inforcing other problems, seems to be ok. This is a fun one. tar and cpio can create setuid files too. None of these are a problem because you still can't give away a setuid file. H'm. On the other hand, uudecode making things setuid can cause problems if root unpacks it and other users use it... Mind you, if you're using binary executables from off the net, you deserve what you get ;-) -- Chris Lewis, clewis@ferret.ocunix.on.ca or ...uunet!mitel!cunews!latour!ecicrl!clewis Psroff support: psroff-request@eci386.uucp, or call 613-832-0541 (Canada) **** somebody's mailer is appending .bitnet to my From: address. If you see this, please use the address in the signature, and send me a copy of the headers of the mail message with the .bitnet return address. Thanks!