From owner-freebsd-security Mon Jan 22 13:47:55 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id NAA17510 for security-outgoing; Mon, 22 Jan 1996 13:47:55 -0800 (PST) Received: from statler.csc.calpoly.edu (statler-srv.csc.calpoly.edu [129.65.241.4]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id NAA17503 for ; Mon, 22 Jan 1996 13:47:53 -0800 (PST) Received: (from nlawson@localhost) by statler.csc.calpoly.edu (8.6.12/N8) id NAA09887; Mon, 22 Jan 1996 13:47:41 -0800 From: Nathan Lawson Message-Id: <199601222147.NAA09887@statler.csc.calpoly.edu> Subject: Ownership of files/tcp_wrappers port To: security@freebsd.org Date: Mon, 22 Jan 1996 13:47:40 -0800 (PST) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@freebsd.org Precedence: bulk Hi there. Two issues that I have been considering. First, I don't mean to beat a dead horse, but I think this issue has never been adequately considered: less "bin" ownership of files and directories. The advantages of more root-owned directories and files are that root is usually mapped to nobody on NFS, so that would add a small amount of security for people who carelessly misuse NFS. Secondly, and more importantly, the root UID is treated much much differently than all other uids (including bin). Programs like "login" almost never allow root logins from remote. However, since bin is a normal user, it can log in from anywhere (yes, I know about login.access, but perhaps you should be putting bin in the "never log in" configuration then). What are the advantages of making files owned by bin? Well, it looks nice when you're doing an ls and you'd like to know if you're in a binaries directory or not. Are there any more? I really have not heard a convincing argument for bin ownership other than "too many files are owned by root". Remember that the Unix environment is bipolar: root and everyone else. Making files owned by bin does NOT provide multiple levels of security, it only puts them in the user domain (yes, again, bin should be protected, but there are nowhere near as many checks to protect the bin account as there are for root). I say to put all your eggs in the root basket and guard that basket very carefully. Secondly, I was wondering why the tcp_wrappers distribution didn't make it into the source tree instead of being a port. It's a pretty small program that hasn't received too many changes recently. It's very worthwhile and libwrap.a can be linked into portmap and ypserv a lot more easily (even making this the default, perhaps). I think it would be a good idea to move it into the main distribution and provide it with some sample, wide-open access rules (permit everything, but perhaps have some comments that indicate some sample rules). That way, a fresh FreeBSD install would have the option of adding access control just by editting /somedir-to-be-argued/hosts.{allow,deny}. People who didn't care about access control would not find it limiting because all services would be allowed (and logged). The only argument I can see against doing this is that clueless first-time users might screw up the allow files, and post tons of "TELNETD NOT WORKING" questions, but as long as the files are default permit-everything, they'd have to go out of their way to screw things up. I don't see the port as being hard to move into the source tree because Wietse uses FreeBSD as a development platform and the code is well-written. Also, you've already used his logdaemon and portmap code, so why not tcp_wrappers? Thanks for considering my suggestions and producing such a good product. -- Nate Lawson \Yeah, I was dreaming through the 'howzlife', yawning, car black, Owner: \when she told me 'mad and meaningless as ever...' and a song Cal Poly State \came on the radio like a cemetery rhyme for a million crying University \corpses in their tragedy of respectable existence. - BR