From owner-freebsd-security Mon Jan 25 04:37:51 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id EAA09375 for freebsd-security-outgoing; Mon, 25 Jan 1999 04:37:51 -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 EAA09370 for ; Mon, 25 Jan 1999 04:37:50 -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 HAA15584; Mon, 25 Jan 1999 07:37:20 -0500 (EST) Date: Mon, 25 Jan 1999 07:37:20 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: Warner Losh cc: Coranth Gryphon , cjclark@home.com, freebsd-security@FreeBSD.ORG Subject: Re: bin Directory Ownership In-Reply-To: <199901250009.RAA06600@harmony.village.org> 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 Sun, 24 Jan 1999, Warner Losh wrote: > bin owned files can be more insecure than root owned files. How you > ask? nfs is one way. When you have bin owned files, they can be > changed remotely by the user bin. However, unless you specifically > enable trusting remote root, root owned files cannot be changed like > that. Diskless machines would create a possible vulnerability here if > one of them was compromised. It is arguable that if you export a file system via NFS non-readonly, then you intend for the files to be modified. There are also a number of files in the binary directories are owned by non-root by virtue of the whole setuid thing (for example, the man command is setuid man, and also frequently run). These may be modified if the file system is NFS-exported writable. Another good suggestion then, for the diskless folks, is that your server shoud probably not export its own /usr, instead an /exports/usr. This is convenient because it allows you to have your file server track a different version of FreeBSD, also, and if you have /var in /usr/var (fairly common) then various pieces of functionality there are also at risk. > It has been argued that root owned files are vulnerable when someone > breaks root. This is true. However, bin owned files are also > vulnerable to change when root is broken. When bin is broken, bin > owned files are also vulnerable. I would hypothesize that many of the supporting 'sandbox' users constitute a security risk, including daemon, operatory, bin, tty, man, and uucp. This is by virtue of both regular system functionality and common usage. As I've posted once or twice, I'm in the process of auditing file ownership under FreeBSD and the setuid-based delegation of uid privileges. I'm doing this by adding POSIX.1e auditing to the FreeBSD kernel, and then analyzing executions and other trust-related events to generate trust graphs for each active uid. I hope to post preliminary results in a few weeks; hopefully they will be useful in tightening FreeBSD (and other UNIXes) security. 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