The 'Security Digest' Archives (TM)

Archive: About | Browse | Search | Contributions | Feedback
Site: Help | Index | Search | Contact | Notices | Changes

ARCHIVE: Unix 'Security Mailing List' - Archives (1984 - 1987)
DOCUMENT: Unix 'Security Mailing List' #2 1985-01-06 (1 file, 1917 bytes)
NOTICE: recognises the rights of all third-party works.


Date:  6 Jan 1985 1940-MST (Sunday)
Subject: Security Mail List,  #2

Well, this is the first real edition of the security mailing list (#1 was
just me seeking advice from those who had expressed interest at the time
about how to run this thing).  To start everything off I'm going to
publish the list of people on the mailing list.  Whenever anyone new
joins, that will also be noted.

I've gotten a lot of response from all of you out there.  There are 42
people on the list right now, and about 65 on the as-yet-to-be-oked list.
Most of the responses concerning security of the list itself supported a
standard mailing list with only the root-user check for membership.  By
the way, as far as oks go, only three downchecks have been tallied.  All
three concern student(s) at major universities who have apparently caused
trouble, but are now on other systems still affiliated with the schools.
Strange pattern.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

From: nbires!ut-sally!harvard!rtm

The internal security of a UNIX system depends on the integrity of
a large number of files, where integrity includes protection modes,
contents, and the modes of the directories above a given file. Modes
and owners can easily change for the worse on a system with many
system administrators; the problems of the sort that we notice around
here mostly involve administrators with umasks of 027 who inadvertently
create unreadable files, but files with excessively lax permissions
crop up now and then, too. Even more worrysome is the problem of
detecting that a file has been illegitimately modified -- if somebody
noted that /usr/local/emacs was generally writeable and installed some
subtle trojan horse in it, how long would it take before you noticed it?

My question is whether any of you have software which maintains lists
of permissable modes (or paradigms for determining reasonable ones)
and perhaps checksums for files and periodically traverses the file
heirarchy looking for changes. This may seem like extreme paranoia to
you, but in a large comp center environment it's really not.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

(I had this laying around - thought I'd publish it here. It concerns the
fix for the infamous kmem problem identified on the net quite a long time
ago. Someone posted a password grabber using this bug about a year ago, and
started something of a furor -- lmc)

Path: denelcor!hao!hplabs!sri-unix!lepreau@utah-cs

I seem to remember doing this about a year ago too.  Well, we
run with 600 kmem/mem here, and here's the list of pgms which need
to read it.  We make them setgid.  Note that if you have a 4.1 or
below system setgid pgms are not safe, and they should be setuid
something: try to avoid root.

Note: rogue should be included (in order to get the load avg),
but is not cause as distributed with 4.2 it doesn't work anyway,
cause rogue resets the gid right after opening the score file, and
never again.

#! /bin/csh -f
set d = /usr/ucb
set pgms = (/etc/dmesg /etc/pstat /etc/trpt /bin/ps /usr/bin/iostat \
 /usr/new/dbid /usr/local/filepos /usr/local/lib/emacs/loadst \
 $d/gcore $d/gprof $d/netstat $d/sysline $d/w $d/vmstat)
/etc/chown root $pgms
chgrp MEM $pgms
chmod 2755 $pgms
chgrp MEM /dev/mem /dev/kmem
chmod 640 /dev/mem /dev/kmem
ls -lg /dev/mem /dev/kmem $pgms

Here's the complete list. Those preceded by '-' we didn't make setgid
cause only root needs to run them.  kgmon is questionable.
==== /etc
==== /bin
==== /usr/bin
==== /usr/ucb
==== /usr/local
==== /usr/new
==== /usr/local/lib/emacs
==== /usr/games