From owner-freebsd-bugs Sat Jan 27 14:21:55 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id OAA05613 for bugs-outgoing; Sat, 27 Jan 1996 14:21:55 -0800 (PST) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id OAA05605 for ; Sat, 27 Jan 1996 14:21:49 -0800 (PST) Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id XAA00294; Sat, 27 Jan 1996 23:21:45 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id XAA01850; Sat, 27 Jan 1996 23:21:44 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.7.3/8.6.9) id XAA24872; Sat, 27 Jan 1996 23:19:26 +0100 (MET) From: J Wunsch Message-Id: <199601272219.XAA24872@uriah.heep.sax.de> Subject: Re: Not Exactly a Bug, but a Crack To: dhawk@netcom.com (David H) Date: Sat, 27 Jan 1996 23:19:25 +0100 (MET) Cc: bugs@freebsd.org Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199601272046.MAA28965@netcom13.netcom.com> from "David H" at Jan 27, 96 12:46:07 pm X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-bugs@freebsd.org Precedence: bulk As David H wrote: > > I check COPS and got the same three items it reported in November > and December: > 1. doesn't like the 'toor' account (second root account), Hmmm. Well, at least, it's disabled. Whether or not multiple UID 0 accounts are a security hole or not is a matter of taste. I usually don't use `root' at all, except that it is there so the files will belong to user `root'. > 2. /etc/security is readable (but only to group wheel), and I don't think group wheel is much to care. It's a compromise. With an /etc/security readable to group wheel, the potential adminst have less need to acutally `su' since they can have a look at the file without. > 3. /var/spool/uucppublic is world-writeable (but nobody's written to > it). It's supposed to. User uucp writes there (incoming uucp job), and the destination user is supposed to be able to read and delete the file there. (Or vica verse.) -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-)