From owner-freebsd-security Tue Jan 23 21:31:52 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id VAA25138 for security-outgoing; Tue, 23 Jan 1996 21:31:52 -0800 (PST) Received: from argus.flash.net (root@[206.149.24.19]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id VAA25125 for ; Tue, 23 Jan 1996 21:31:47 -0800 (PST) Received: (from lists@localhost) by argus.flash.net (8.6.12/8.6.12) id AAA00965; Tue, 23 Jan 1996 00:41:20 -0600 From: mailing list account Message-Id: <199601230641.AAA00965@argus.flash.net> Subject: Re: Ownership of files/tcp_wrappers port To: nlawson@statler.csc.calpoly.edu (Nathan Lawson) Date: Tue, 23 Jan 1996 00:41:19 -0600 (CST) Cc: freebsd-security@freebsd.org In-Reply-To: <199601222147.NAA09887@statler.csc.calpoly.edu> from "Nathan Lawson" at Jan 22, 96 01:47:40 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-security@freebsd.org Precedence: bulk In reply: > 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 which is a lame argument to boot. user and group ownership should be based on function, instead of preference. I pity the poor fool who changes the ownership of a setuid script to root, or a setgid script to wheel... same for setuid/gid programs that give any form of shell access.. bin is nice for non-threat functions in that it has no password assigned, thus disabling any logins... of course there is that one fool in a million who will assign a password for bin, thus making it vulnerable. ghost accounts and groups are not a problem. improper use of permissions bits, stickyness of dirs, and setuid/gid are problems. the plaintext nature of most tcp connections is even a greater threat. > 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 really see nothing wrong with it being a port, as long as it is in source form, not as a package. security packages are a matter of preference, and should be hackable and/or replacable for any situation. I do see areas where permissions could be changed up a bit... world permissions on binaries should always be 1, and for most of them, a 711 would be adequate... this would be best done in the distribution, and makefiles so we don't have to do it ourselves every time a new release is made. the easiest way for hacker to learn a program's weakneses is from a debugging dump of a readable binary. this in itself will only stop the casual hacker. with the avalability of the sources, a determined hacker could probably find holes with a little effort. Jim -- All opinions expressed are mine, if you | "I will not be pushed, stamped, think otherwise, then go jump into turbid | briefed, debriefed, indexed, or radioactive waters and yell WAHOO !!! | numbered!" - #1, "The Prisoner" jbryant@argus.flash.net - FlashNet Communications - Ft. Worth, Texas