From owner-freebsd-security Sun Mar 14 11:16:23 1999 Delivered-To: freebsd-security@freebsd.org Received: from woodstock (lakertya-1-70.mdm.mkt.execpc.com [169.207.118.70]) by hub.freebsd.org (Postfix) with ESMTP id 0CD0415038 for ; Sun, 14 Mar 1999 11:16:13 -0800 (PST) (envelope-from hamilton@pobox.com) Received: from pobox.com (localhost [127.0.0.1]) by woodstock (Postfix) with ESMTP id 804833F; Sun, 14 Mar 1999 13:15:47 -0600 (CST) To: Robert Watson Cc: Peter Jeremy , freebsd-security@FreeBSD.ORG Subject: Re: ACL's In-reply-to: Your message of "Sun, 14 Mar 1999 12:24:43 EST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 14 Mar 1999 13:15:47 -0600 From: Jon Hamilton Message-Id: <19990314191547.804833F@woodstock> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message , Robert Watson wrote: } On Sun, 14 Mar 1999, Peter Jeremy wrote: } } > Robert Watson wrote: } > } > >I.e., user creates a hard link to /usr/sbin/somesetuidbin to } > >/usr/tmp/mytemp. } > } > Normal users shouldn't have write permission anywhere on a partition } > containing system binaries - this also removes the problem. (Note } > that /usr/tmp is accessible only by root under FreeBSD). } } But many common FS arrangements do use the same partition for a } world-writable directory and the binaries. For example: } } /var on /usr/var (/var has /var/tmp) } /usr/local/ on /usr (The tex port requires a world-writable temp } directory) } /tmp on / (/sbin is usually on /; default install I believe) } /home on /usr/home (default install I believe) } } I like the idea of the FS namespace having consistent } semantics--counter-intuitive security behavior like "the system is } relatively secure as long as you don't partition the system in any way } that allows these files to be on the same partition as these files..." } seems best to be avoided. } } I think hard links are neat, et al, but I really don't think they add any } new useful functionality above symlinks, and they can certainly introduce } new problems. They save a little disk space here and there (as long as } you don't recursive move anything)... Symbolic links are a nightmare if you move things around. They also won't work across chroot boundaries, and can cause problems across NFS particularly in environments using the automounter -- if you use absolute symbolic links (i.e. ones which go through /) you get a surprise when someone on a remote workstation tries to use them and they try to reference / on the _remote_ machine. Use relative symbolic links and you may get surprises too. -- Jon Hamilton hamilton@pobox.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message