From owner-freebsd-security Wed Jan 24 02:20:14 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id CAA16960 for security-outgoing; Wed, 24 Jan 1996 02:20:14 -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 CAA16954 for ; Wed, 24 Jan 1996 02:20:09 -0800 (PST) Received: (from nlawson@localhost) by statler.csc.calpoly.edu (8.6.12/N8) id CAA11895; Wed, 24 Jan 1996 02:19:52 -0800 From: Nathan Lawson Message-Id: <199601241019.CAA11895@statler.csc.calpoly.edu> Subject: Re: Ownership of files/tcp_wrappers port To: msmith@atrad.adelaide.edu.au (Michael Smith) Date: Wed, 24 Jan 1996 02:19:51 -0800 (PST) Cc: security@freebsd.org In-Reply-To: <199601240837.TAA26571@genesis.atrad.adelaide.edu.au> from "Michael Smith" at Jan 24, 96 07:07:59 pm 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 > 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. This "someone" is not well-protected enough to own critical things like binaries. Until you can prove to me that a bin compromise is as hard as a root compromise, I won't relent. Consider NFS, hosts.equiv, and login. None of those will stop a bin intrusion. If you can log in as bin, login will let you. If you can access a filesystem via NFS, bin access is allowed while root is mapped to nobody. Hosts.equiv allows _every_ user except root to access the equivalent account. Of course, I don't think rlogin and NFS are secure protocols. But you should od your best to protect what little security you do have. Saying "oh, the protocols are fundamentally flawed, let's just throw security out the door" is lazy. > > 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. Because "just binaries" are run by root every day. You wouldn't run a program owned by me (I hope!) Why would you let root run programs owned by someone else? Especially since the root account has more protection than bin. > > 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. Nope. It uses /bin/sh if the shell is null. I prefer /noshell. >From login.c: if (*pwd->pw_shell == '\0') pwd->pw_shell = _PATH_BSHELL; -- 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