From owner-freebsd-stable@FreeBSD.ORG Mon Nov 17 09:03:27 2003 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5D92A16A4CE for ; Mon, 17 Nov 2003 09:03:27 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0804843FB1 for ; Mon, 17 Nov 2003 09:03:26 -0800 (PST) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.9p2/8.12.9) with ESMTP id hAHH1MMg066517; Mon, 17 Nov 2003 12:01:22 -0500 (EST) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)hAHH1M4J066514; Mon, 17 Nov 2003 12:01:22 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Mon, 17 Nov 2003 12:01:22 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: "Marc G. Fournier" In-Reply-To: <20031115211530.J34088@ganymede.hub.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-stable@freebsd.org Subject: Re: memory locking in a jail? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Nov 2003 17:03:27 -0000 On Sat, 15 Nov 2003, Marc G. Fournier wrote: > With gpg setuid root, I'm getting the following 'insecure memory' issue > when running inside of a jail: > > gpg: WARNING: using insecure memory! > > from the FAQ, it has to do with memory locking ... is this something > that can't be done inside of a jail? Or just an issue with jail in 4.x? FreeBSD requires privilege to lock pages in memory; right now, that privilege check does not allow mlock() to be used in a jail. You can modify that privilege check locally to permit privileged users in jail() to use mlock() by editing vm_mmap.c to pass the PRISON_ROOT flag into suser_cred() or suser_xxx(), depending on whether you're using -CURRENT or -STABLE. There's #ifdef'd out code that permits locking of memory for unprivileged processes based on a resource limit, but I'm not sufficiently familiar with the history of that to comment on which it's commented out. Locked memory is a very precious resource, though, so any reduction of the privilege level necessary to lock memory needs to be thought through very carefully, and in the context of any past history of the issue. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Network Associates Laboratories