From owner-freebsd-arch@FreeBSD.ORG Tue Oct 31 22:34:21 2006 Return-Path: X-Original-To: arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1DE0816A407 for ; Tue, 31 Oct 2006 22:34:21 +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 C822943D46 for ; Tue, 31 Oct 2006 22:34:20 +0000 (GMT) (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 9CD3B46DD4; Tue, 31 Oct 2006 17:34:20 -0500 (EST) Date: Tue, 31 Oct 2006 22:34:20 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Alexander Leidinger In-Reply-To: <20061031203247.15787e75@Magellan.Leidinger.net> Message-ID: <20061031222146.M96078@fledge.watson.org> References: <20061031092122.D96078@fledge.watson.org> <20061031203247.15787e75@Magellan.Leidinger.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: arch@FreeBSD.org Subject: Re: New in-kernel privilege API: priv(9) 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: Tue, 31 Oct 2006 22:34:21 -0000 On Tue, 31 Oct 2006, Alexander Leidinger wrote: > Quoting Robert Watson (Tue, 31 Oct 2006 09:43:45 +0000 (GMT)): > >> (2) Sweep of the remaining kernel files, cleaning up privilege checks, >> replacing suser()/suser_cred() calls, etc, across the kernel. > > What about denying access to the dmesg in a jail? I noticed in the run of > the periodic scripts in jails that I can see the segfaults of programs in > other jails (stock -current, but I haven't seen such a privilege in your > list of allowed privileges for a jail). A quick test revealed that I'm able > to see the complete dmesg. > > From an user point of view I don't want to get confused by broken stuff in a > jail of someone else (shared hosting) and I don't want to let other people > know what programs I run (in case they are failing). A couple of years ago, I added a sysctl that could be set to require privilege in order to read the kernel message buffer. When that sysctl is set, "unprivileged" (i.e., unable to read the buffer) includes root processes in jail. I agree that reading the message buffer is probably something that should be restricted even for root processes in jail, although in some senses the current model is quite consistent with normal behavior (privileged vs. unprivileged). I'd be quite happy to review a patch to limit that sysctl to outside of jail, perhaps keyed to a specific sysctl that can be disabled to allow dmesg in jail. Robert N M Watson Computer Laboratory University of Cambridge