Date: Tue, 23 Jan 1996 00:41:19 -0600 (CST) From: mailing list account <lists@argus.flash.net> To: nlawson@statler.csc.calpoly.edu (Nathan Lawson) Cc: freebsd-security@freebsd.org Subject: Re: Ownership of files/tcp_wrappers port Message-ID: <199601230641.AAA00965@argus.flash.net> In-Reply-To: <199601222147.NAA09887@statler.csc.calpoly.edu> from "Nathan Lawson" at Jan 22, 96 01:47:40 pm
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199601230641.AAA00965>