From owner-freebsd-security Tue Nov 17 19:50:32 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA11409 for freebsd-security-outgoing; Tue, 17 Nov 1998 19:50:32 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from fledge.watson.org (FLEDGE.RES.CMU.EDU [128.2.93.229]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA11392 for ; Tue, 17 Nov 1998 19:50:28 -0800 (PST) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.8.8/8.8.8) with SMTP id WAA28702; Tue, 17 Nov 1998 22:49:45 -0500 (EST) Date: Tue, 17 Nov 1998 22:49:45 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: Andrew McNaughton cc: freebsd-security@FreeBSD.ORG Subject: Re: groups In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, 18 Nov 1998, Andrew McNaughton wrote: > Too much of a tangent to to put it into the existing thread: Can someone > give me a description of why we have user and group 'bin'? > > Clearly there's a good deal of variance in whether things get installed as > root/wheel or bin/bin. I'm not at all clear on what it is intended to > acheive, when it should be used and why. > > Is there any documentation of the purpose and implications of the groups > used by freebsd as installed? That has never been entirely clear to me. Bin is one of a whole class of users that, if the /usr partition is on a writable file system, is essentially equivilent to the root user. That is, the root user executes programs owned by the user bin (and others) almost constantly during routine activities. Anyone acting as user 'bin' could trojan any of the system binaries quite effectively to obtain root access. This is the case for any binary run by root (we all recall why never to put the current directory in the path :). This is in fact quite serious in a few cases. For example, the UUCP account owns a number of binaries in the root path. At first this seems not-too-serious, as you ask yourself how often do I run these? :) The you realize that the daily script runs them every night as root (uustat I think). Therefore within 24 hours, anyone who has cracked the UUCP account, if /usr is writable, also has root access. So a buffer overflow in a uucp program can result in root access even though the uucp binaries are usually only setgid, or setuid uucp. (uuname for example) It seems good intuitively to have binaries owned by different users, but no particularly good reasons come to mind for having everything owned by bin. Except possibly in the case that /usr is NFS mounted, and the NFS server does not wish to export root writability on the FS? Even that seems pretty lame as reasons go. Robert N Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: 03 01 DD 8E 15 67 48 73 25 6D 10 FC EC 68 C1 1C Carnegie Mellon University http://www.cmu.edu/ TIS Labs at Network Associates, Inc. http://www.tis.com/ SafePort Network Services http://www.safeport.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message