Date: Sun, 14 Mar 1999 15:40:24 -0500 (EST) From: Robert Watson <robert@cyrus.watson.org> To: Jon Hamilton <hamilton@pobox.com> Cc: Peter Jeremy <peter.jeremy@auss2.alcatel.com.au>, freebsd-security@FreeBSD.ORG Subject: Re: ACL's Message-ID: <Pine.BSF.3.96.990314152855.5121H-100000@fledge.watson.org> In-Reply-To: <19990314191547.804833F@woodstock>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 14 Mar 1999, Jon Hamilton wrote: > In message <Pine.BSF.3.96.990314121837.5121C-100000@fledge.watson.org>, Robert > Watson wrote: > } On Sun, 14 Mar 1999, Peter Jeremy wrote: > } > } > Robert Watson <robert@cyrus.watson.org> 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. No matter what behavior we choose, we get some amount of inconsistency--this is the effect of violating the one-name<->one-object behavior. However, my argument is that hard links result in security concerns that symlinks will not result in--e.g., a certain set of race conditions and the ability of a user to preserve binaries that the owner does not want preserved. And that it does this in a counter-intuitive way across partitions which are (normally) not visible distinctions from the point of view of the user. Symlinks have consistent behavior across the entire namespace, and leaving aside the garbage collection issue, provide pretty much all functionality hardlinks do. This garbage-collection issue is in fact the change that I want: the names referencing an object should obey the semantics required by the controller of the original object, not of anyone who is able to read it at any point in its history. Symlinks allow me to revoke access to an object trivially, and consistently with the hierarchal directory behavior. And since files in UNIX convey capabilities, this is actually extremely important. In response to the absolute symlink concern: this is why in my example (see some email or another) I used only relative symlinks. You'll find that, given the arbitrary way partitioning occurs, this is the only useful way to manage hard links also: the user can specify any directory-separated partioning scheme they choose when they install, and most of them make sense. Removing hard links helps us in a number of ways: it allows for a unique name relative to a partition for a file (great for auditing and TPE); it allows atomicity and reliability for deletion, along with prevention of inode hijacking. It provides a more consistent view of the FS to the average user: symlinks work across partitions, network file systems, etc. It allows a unique set of permissions to be evaluated for a file, ensuring that a common set are applied to all users. It allows revocation of file access to be ensured by the owner. As with all aliasing, symlinks can result in surprises. I argue that they result in fewer surprises; in particular, fewer security-related surprises. How about sysctl vfs.allow_hardlinks? :-) If there isn't one already, I'll submit patches. It would restrict only creation of new hard links. Plus possibly a utility to flatten existing hard links by a) copying the file to a temporary location, b) unlinking the original, and c) renaming the copy back to the original name, for any file with >1 references. 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.990314152855.5121H-100000>