From owner-svn-src-all@FreeBSD.ORG Mon Mar 2 09:02:37 2015 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5D0E0165; Mon, 2 Mar 2015 09:02:37 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 2DC25283; Mon, 2 Mar 2015 09:02:36 +0000 (UTC) Received: from Julian-MBP3.local (50-196-156-133-static.hfc.comcastbusiness.net [50.196.156.133]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id t2292ZsY003205 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 2 Mar 2015 01:02:36 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <54F42726.3000602@freebsd.org> Date: Mon, 02 Mar 2015 01:02:30 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Ian Lepore , src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r279361 - in head: sys/kern sys/sys usr.sbin/jail References: <201502271628.t1RGSurE067472@svn.freebsd.org> In-Reply-To: <201502271628.t1RGSurE067472@svn.freebsd.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2015 09:02:37 -0000 On 2/27/15 8:28 AM, Ian Lepore wrote: > > Log: > Allow the kern.osrelease and kern.osreldate sysctl values to be set in a > jail's creation parameters. This allows the kernel version to be reliably > spoofed within the jail whether examined directly with sysctl or > indirectly with the uname -r and -K options. > [..] > There is no sanity or range checking, other than disallowing an empty > release string or a zero release date, by design. The system > administrator is trusted to set sane values. Setting values that are > newer than the actual running kernel will likely cause compatibility > problems. > I would think that you could at set time ensure that only older releases were allowed.. I'm not sure what the rule would be with sub-sub-jails.. older than parent, or older than base system..?