From owner-freebsd-security@FreeBSD.ORG Wed Apr 30 18:45:18 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E6CB8538; Wed, 30 Apr 2014 18:45:18 +0000 (UTC) Received: from anubis.delphij.net (anubis.delphij.net [64.62.153.212]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "anubis.delphij.net", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id CCAD015FA; Wed, 30 Apr 2014 18:45:18 +0000 (UTC) Received: from zeta.ixsystems.com (unknown [69.198.165.132]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by anubis.delphij.net (Postfix) with ESMTPSA id 53A4E23E36; Wed, 30 Apr 2014 11:45:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delphij.net; s=anubis; t=1398883511; bh=ZvRcMQ8mkiDqzflfgfSPZ+J4o0SoCtr5bJzg2jLXg0g=; h=Date:From:Reply-To:To:Subject:References:In-Reply-To; b=u0nj9IFCR8jBuMZqKNCeJVj4ZUr2AE7K65fTHzrIvZZCuXwaueqxhr+dFSNXRDGZT 2n821bx3ue5TBskh/JkK1f+3nGUx9OwiuS3lGM4ltSQ0c/6G7DYsgoMIHHTReQSrOq fOQC3IkBIFOQyThephfpGUiIjiguRRDED0nmjNt8= Message-ID: <536144B6.7030305@delphij.net> Date: Wed, 30 Apr 2014 11:45:10 -0700 From: Xin Li Organization: The FreeBSD Project MIME-Version: 1.0 To: Matthew Seaman , freebsd-security@freebsd.org Subject: Re: FreeBSD Security Advisory FreeBSD-SA-14:07.devfs References: <201404300435.s3U4ZA45093722@freefall.freebsd.org> <5360D9CF.6000103@freebsd.org> In-Reply-To: <5360D9CF.6000103@freebsd.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: d@delphij.net List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 18:45:19 -0000 On 04/30/14 04:09, Matthew Seaman wrote: > On 04/30/14 05:35, FreeBSD Security Advisories wrote: >> Then apply the default ruleset for jails on a devfs mount using: >> >> devfs -m ${devfs_mountpoint} rule -s 4 applyset >> >> Or, alternatively, the following command will apply the ruleset >> over all devfs mountpoints except the host one: >> >> mount -t devfs | grep -v '^devfs on /dev ' | awk '{print $3;}' | >> \ xargs -n 1 -J % devfs -m % rule -s 4 applyset >> >> After this, the system administrator should add the following >> configuration to /etc/rc.conf to make it permanent, so the above >> operations do not have to be done each time the host system >> reboots. >> >> devfs_load_rulesets="YES" >> > > Verb. Sap. Doing this in a jail where you're running net-snmpd > will prevent snmpd from starting up correctly. > > Apr 30 12:02:30 xxxxx snmpd[33871]: init_kmem: kvm_openfiles > failed: /dev/mem: No such file or directory Apr 30 12:02:30 xxxxx > snmpd[33871]: Agent initialization failed This is pretty much expected behavior. The reason is that /dev/mem provides an interface to physical memory, this would have defeated the purpose of doing jails by definition. It would be interesting to find out if we could teach net-snmpd to use alternative methods to access data it needs, e.g. via sysctl I think? Not all data are exposed via sysctl at this time, though. Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die