Date: Wed, 24 Jan 1996 19:07:59 +1030 (CST) From: Michael Smith <msmith@atrad.adelaide.edu.au> To: lists@argus.flash.net (mailing list account) Cc: nlawson@statler.csc.calpoly.edu, freebsd-security@freebsd.org Subject: Re: Ownership of files/tcp_wrappers port Message-ID: <199601240837.TAA26571@genesis.atrad.adelaide.edu.au> In-Reply-To: <199601230641.AAA00965@argus.flash.net> from "mailing list account" at Jan 23, 96 00:41:19 am
next in thread | previous in thread | raw e-mail | index | archive | help
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." [[
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199601240837.TAA26571>