Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!cs.utexas.edu!uunet!beartrk!ceilidh!dnichols From: dnichols@ceilidh.beartrack.com (DoN Nichols) Newsgroups: comp.sys.3b1 Subject: Re: COPS security audit and the unix pc. Message-ID: <1991Mar28.035200.725@ceilidh.beartrack.com> Date: 28 Mar 91 03:52:00 GMT References: <1991Mar23.004007.2024@shibaya.lonestar.org> <1991Mar26.225255.6048@ferret.ocunix.on.ca> Organization: D and D Data, Vienna, VA. Lines: 71 In article <1991Mar26.225255.6048@ferret.ocunix.on.ca> clewis@ferret.ocunix.on.ca (Chris Lewis) writes: >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. [ ... ] >>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... Is it tolerable to run B-news on the 3b1? I am getting just a partial feed, and even with C-news it can take over an hour to digest a large day's shipment, like today's. [ ... ] >>> 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) Except that the HDB version from THE STORE made the lockfiles live in the same old place, to keep compatability with other stuff in the machine. :-( [ ... ] >>> 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. I don't like leaving a roadmap with a nice heavy guideline for potential troublemakers/trojan_horse_builders, even though one cannot directly dial into this system. [ ... ] >>> 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 ;-) Like the binary (with source) that caused all the furor in the 386 unix newsgroup? :-) Can YOUR computer enjoy a safe sleep? :-) DoN. -- Donald Nichols (DoN.) | Voice (Days): (703) 664-1585 D&D Data | Voice (Eves): (703) 938-4564 Disclaimer: from here - None | Email: --- Black Holes are where God is dividing by zero ---