Date: Tue, 2 Jan 2007 23:07:55 +0000 (GMT) From: Robert Watson <rwatson@FreeBSD.org> To: Colin Percival <cperciva@freebsd.org> Cc: Ceri Davies <ceri@submonkey.net>, "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org> Subject: Re: default value of security.bsd.hardlink_check_[ug]id Message-ID: <20070102230111.M7974@fledge.watson.org> In-Reply-To: <4599E57C.5090904@freebsd.org> References: <459745DA.1010801@freebsd.org> <20061231124431.GG97921@submonkey.net> <4599E57C.5090904@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 1 Jan 2007, Colin Percival wrote: > Ceri Davies wrote: >> On Sat, Dec 30, 2006 at 09:08:42PM -0800, Colin Percival wrote: >>> I'd like to make security.bsd.hardlink_check_[ug]id default to 1, starting >>> with FreeBSD 7.x. This would make it impossible for a user to create a hard >>> link to a file which he does not own. >> >> a) you have provided no rationale; > > Allowing users to create hard links to files which they do not own creates > problems: > 1. If disk quotas are enabled, a user can waste another user's disk quota by > making it impossible for said other user to delete files. > 2. It becomes difficult to apply security fixes for issues involving setuid > binaries, since a local attacker could create hard links to all the setuid > binaries (or at least those on filesystems where he can write somewhere) and > wait for a security issue to be found. I find the second argument here most compelling, and use it as an example frequently when complaining about hard links. Hard links also one of the elements that makes it difficult to usefully generate names for file system objects, due to their introducing ambiguity. > I honestly can't see why it was ever possible for users to create hard links > to files which they don't own; hopefully someone can provide the historical > background and tell me if the original reasons (whatever they were) still > apply. It's generally consistent with the world view that says names of objects are property of the directory they appear in. In terms of history: remember that before there was rename(), there were link() and unlink(), and if you want to give users who own directories the right to rename within those directories, that required the ability to link() and unlink(). That model is quite consistent, but interacts poorly with the way users, and especially administrators, expect the system to work. > If it isn't possible to outlaw such hard linking entirely, I'd like to make > it impossible by default for > (a) a user to create a hard link to a setuid file which they do not own, and > (b) a user to create a hard link to a setgid file if they are not in the right > group, > since these are the important cases for security. I think we should give the change in defaults (after cleaning up the implementation per bde's and my comments) for the sysctl a trial run in 7-CURRENT for a few months and see what breaks. If we get lots of complaints, we can back out the change, refine it, etc. History suggests that this isn't a foolproof way to find problems (remember how long it took to shake out changes in signaling protection), but it may well turn up something useful. Robert N M Watson Computer Laboratory University of Cambridge
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070102230111.M7974>