From owner-freebsd-security Sun Mar 14 12:16:38 1999 Delivered-To: freebsd-security@freebsd.org Received: from host07.rwsystems.net (kasie.rwsystems.net [209.197.192.103]) by hub.freebsd.org (Postfix) with ESMTP id C601B14F24 for ; Sun, 14 Mar 1999 12:16:35 -0800 (PST) (envelope-from jwyatt@RWSystems.net) Received: from kasie.rwsystems.net([209.197.192.103]) (3278 bytes) by host07.rwsystems.net via sendmail with P:esmtp/R:bind_hosts/T:inet_zone_bind_smtp (sender: ) id for ; Sun, 14 Mar 1999 13:46:14 -0600 (CST) (Smail-3.2.0.104 1998-Nov-20 #1 built 1998-Dec-24) Date: Sun, 14 Mar 1999 13:46:13 -0600 (CST) From: James Wyatt To: freebsd-security@FreeBSD.ORG Subject: Re: ACL's 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 Sun, 14 Mar 1999, Robert Watson wrote: > On Sun, 14 Mar 1999, Peter Jeremy wrote: > > 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) For /tmp and /home, these are best as separate filesystems if you have regular users, IMHO. For /var/tmp, maybe there is a good use for a symlink? I'm sorry, but I consider making a world writable directory under /usr/local/ simply *broken*. A symlink would suffice here until the port or package or application folks could be made aware of the sysadmin implications of this behavior (the sudo folks got it right). > 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. Yes, but it's portable. 8{) Some of us have been doing it since we had BSD on the VAXen. Some commercial Unixes (Uni?) ship that way. I also like the idea of a small root filesys and extra /tmp filesys as it moves us closer to a RO root filesys. It makes root backups quicker. In fact, it would be a nice change to the 'auto defaults' disk partitioning portion of our install. > 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)... Symlinks also introduce their own problems. They can point to *nothing* when hard links can't. (esp. post-fsck!) Symlinks also burn inodes and more filesystem space. They are a *real* headache and performance sink on news filesystems. Of course, having worked on *nix systems that had hard links, but no symlinks, I may be biased... I also have used them to do filesystem databases (each directory is an index with a link to the real data nugget. Fast, but table-joins by comparing inodes was tough... 8{( Anyone else remember the UseNet wag who said "Symlinks can turn your filesystem tree into a bramblebush."? Rich Salz, perhaps? - Jy@ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message