From owner-freebsd-security Wed Jan 24 00:30:10 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id AAA09859 for security-outgoing; Wed, 24 Jan 1996 00:30:10 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id AAA09775 for ; Wed, 24 Jan 1996 00:29:57 -0800 (PST) Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.12/8.6.9) id TAA26571; Wed, 24 Jan 1996 19:07:59 +1030 From: Michael Smith Message-Id: <199601240837.TAA26571@genesis.atrad.adelaide.edu.au> Subject: Re: Ownership of files/tcp_wrappers port To: lists@argus.flash.net (mailing list account) Date: Wed, 24 Jan 1996 19:07:59 +1030 (CST) Cc: nlawson@statler.csc.calpoly.edu, freebsd-security@freebsd.org In-Reply-To: <199601230641.AAA00965@argus.flash.net> from "mailing list account" at Jan 23, 96 00:41:19 am MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@freebsd.org Precedence: bulk mailing list account stands accused of saying: > > 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. If nothing else, it's convenient to have "someone" own "system" things. It's _preferable_ that this "someone" isn't a user in the common sense of the word. > user and group ownership should be based on function, instead of preference. Naturally. And if something is "just a binary", why shouldn't it be owned by bin? Only things that need to be owned by root, so that being setuid is useful, should be so. > I pity the poor fool who changes the ownership of a setuid script to root, or Just a point for you to consider; setuid shellscripts _do_not_work_ under FreeBSD. > 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 And no shell either. > 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. Definitely agreed. > 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. Only a determined hacker would bother pulling apart a binary; with the source readily available I can't see any use in preventing read access to system binaries, and a few situations where it'd be a pain. > Jim -- ]] Mike Smith, Software Engineer msmith@atrad.adelaide.edu.au [[ ]] Genesis Software genesis@atrad.adelaide.edu.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control (ph/fax) +61-8-267-3039 [[ ]] "Who does BSD?" "We do Chucky, we do." [[