COPS security audit and the unix pc.

Chris Lewis clewis at ferret.ocunix.on.ca
Wed Mar 27 08:52:55 AEST 1991


In article <1991Mar23.004007.2024 at shibaya.lonestar.org> afc at 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 at ferret.ocunix.on.ca or ...uunet!mitel!cunews!latour!ecicrl!clewis
Psroff support: psroff-request at 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!



More information about the Comp.sys.3b1 mailing list