From owner-freebsd-arch@FreeBSD.ORG Sun Dec 31 15:39:07 2006 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 57EC816A40F; Sun, 31 Dec 2006 15:39:07 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 23FDA13C441; Sun, 31 Dec 2006 15:39:05 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id BF84148BD9; Sun, 31 Dec 2006 10:39:04 -0500 (EST) Date: Sun, 31 Dec 2006 15:39:04 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Ceri Davies In-Reply-To: <20061231124431.GG97921@submonkey.net> Message-ID: <20061231153645.Y8131@fledge.watson.org> References: <459745DA.1010801@freebsd.org> <20061231124431.GG97921@submonkey.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Colin Percival , "freebsd-arch@freebsd.org" Subject: Re: default value of security.bsd.hardlink_check_[ug]id X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Dec 2006 15:39:07 -0000 On Sun, 31 Dec 2006, Ceri Davies wrote: > On Sat, Dec 30, 2006 at 09:08:42PM -0800, Colin Percival wrote: >> FreeBSD Architects, >> >> 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. >> >> Any objections? > > One here, on the grounds that: > > a) you have provided no rationale; > b) that sysctl does not currently seem to be documented anywhere, so > changing its default value would violate POLA. > > There is a longer answer in which I pine after Solaris' privileges(5) again, > or wonder if this can be implemented for "system" processes only using the > new priv(9) API instead. Priv(9) provides a useful foundation for doing something like this, and is a necessary first step to do it. However, to date I've been pretty careful to avoid changing the actual privilege model, just the expression of privilege checking. It should be possibly to implement a more selective privilege model using a MAC Framework policy module today. In the past, the TrustedBSD Project has fully implemented POSIX.1e privileges on FreeBSD, and having looked at the implementation, decided it was very high risk, and likely to lead to more vulnerabilities than it addressed. I think we should think very carefully before changing the OS privilege model, and make sure we're going about it in a robust and low-risk way. Robert N M Watson Computer Laboratory University of Cambridge