Date: Sun, 14 Mar 1999 15:15:56 -0600 From: Jon Hamilton <hamilton@pobox.com> To: Robert Watson <robert+freebsd@cyrus.watson.org> Cc: Peter Jeremy <peter.jeremy@auss2.alcatel.com.au>, freebsd-security@FreeBSD.ORG Subject: Re: ACL's Message-ID: <19990314211556.E37313E@woodstock> In-Reply-To: Your message of "Sun, 14 Mar 1999 15:40:24 EST." <Pine.BSF.3.96.990314152855.5121H-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
} > } 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 The race condition argument actually works *against* symbolic links. } 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. No, they provide all the functionality that hardlinks do that *you* care about. Not every installation is used the same way, and you're simply not going to be able to just do away with hard links by fiat; too many people and things rely upon them. } 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. Nobody is forcing you to use hard links; if you like symbolic links, then use them and your problems are over. } 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 The deletion argument doesn't hold water either; you still have to check whether the name you know something as (and the name you intend to delete) is a symlink or the original file. } 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. So do hard links; simply chmod any one of the links and the others follow. } As with all aliasing, symlinks can result in surprises. I argue that they } result in fewer surprises; in particular, fewer security-related } surprises. I simply don't buy that argument. } How about sysctl vfs.allow_hardlinks? :-) If there isn't one already, I wouldn't have any argument against that, provided that the default is to leave them on. } 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. Ick ick ick! :) -- Jon Hamilton hamilton@pobox.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?19990314211556.E37313E>