ARCHIVE: Unix 'Security Mailing List' - Archives (1984 - 1987)
DOCUMENT: Unix 'Security Mailing List' #2 1985-01-06 (1 file, 1917 bytes)
NOTICE: securitydigest.org recognises the rights of all third-party works.
START OF DOCUMENT
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 dmesg: -ethermap: -kgmon: pstat: -route: -routed: -rwhod: -savecore: trpt: ==== /bin ps: ==== /usr/bin iostat: ==== /usr/ucb gcore: gprof: netstat: sysline: uptime/w: vmstat: ==== /usr/local filepos: -setuid: ==== /usr/new dbid: ==== /usr/local/lib/emacs loadst: ==== /usr/games rogue --------------------------------------------
END OF DOCUMENT
|ISSN 1742-948X 01 (Online) | 2005/03/01 | Copyright 2002-2008 securitydigest.org. All rights reserved.|