From owner-freebsd-security Sun Mar 14 13:16:20 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 4914814E87 for ; Sun, 14 Mar 1999 13:16:16 -0800 (PST) (envelope-from hamilton@pobox.com) Received: from pobox.com (localhost [127.0.0.1]) by woodstock (Postfix) with ESMTP id E37313E; Sun, 14 Mar 1999 15:15:56 -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 15:40:24 EST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 14 Mar 1999 15:15:56 -0600 From: Jon Hamilton Message-Id: <19990314211556.E37313E@woodstock> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org } > } 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