From owner-freebsd-security@FreeBSD.ORG Wed Apr 30 18:46:01 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E6F7A61E for ; Wed, 30 Apr 2014 18:46:01 +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 CBB671616 for ; Wed, 30 Apr 2014 18:46:01 +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 45D9523F52; Wed, 30 Apr 2014 11:46:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delphij.net; s=anubis; t=1398883561; bh=pwgOt4wsBvZFrCyEIPnn5tTqzoKyj8SLUys0dQ2Gu84=; h=Date:From:Reply-To:To:Subject:References:In-Reply-To; b=BYsednDjALXYDHNZjyGQEgrn8QLsjk1CIgIDvtW1c8v8DPUpiPot/a9KMx1LnOhso ZRfHFBsoluelxXj16tm7IKXuR2ruQ8LY/ZJ167jtOkUIuqHK4cHLsiTtaOsY6/564S wjFTQ8wL5jsBWlJEWa3NaytN7KxdO53eEM56FfU4= Message-ID: <536144E8.4020502@delphij.net> Date: Wed, 30 Apr 2014 11:46:00 -0700 From: Xin Li Organization: The FreeBSD Project MIME-Version: 1.0 To: =?ISO-8859-1?Q?Wout_Decr=E9?= , freebsd-security@freebsd.org Subject: Re: FreeBSD Security Advisory FreeBSD-SA-14:07.devfs References: <201404300435.s3U4ZAfe093748@freefall.freebsd.org> <1398849409.4521.12.camel@debian.wout-t440s> In-Reply-To: <1398849409.4521.12.camel@debian.wout-t440s> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit 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:46:02 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 04/30/14 02:16, Wout Decré wrote: > On Wed, 2014-04-30 at 04:35 +0000, FreeBSD Security Advisories > wrote: >> ============================================================================= >> >> FreeBSD-SA-14:07.devfs Security Advisory >> The FreeBSD Project >> >> Topic: devfs rules not applied by default for jails >> >> Category: core Module: etc_rc.d Announced: >> 2014-04-30 Affects: FreeBSD 10.0 Corrected: >> 2014-04-30 04:03:05 UTC (stable/10, 10.0-STABLE) 2014-04-30 >> 04:04:42 UTC (releng/10.0, 10.0-RELEASE-p2) CVE Name: >> CVE-2014-3001 >> >> For general information regarding FreeBSD Security Advisories, >> including descriptions of the fields above, security branches, >> and the following sections, please visit >> . >> >> I. Background >> >> The device file system, or devfs(5), provides access to kernel's >> device namespace in the global file system namespace. >> >> The devfs(5) rule subsystem provides a way for the administrator >> of a system to control the attributes of DEVFS nodes. Each DEVFS >> mount-point has a ``ruleset'', or a list of rules, associated >> with it, allowing the administrator to change the properties, >> including the visibility, of certain nodes. >> >> II. Problem Description >> >> The default devfs rulesets are not loaded on boot, even when >> jails are used. Device nodes will be created in the jail with >> their normal default access permissions, while most of them >> should be hidden and inaccessible. >> >> III. Impact >> >> Jailed processes can get access to restricted resources on the >> host system. For jailed processes running with superuser >> privileges this implies access to all devices on the system. >> This level of access could lead to information leakage and >> privilege escalation. >> >> IV. Workaround >> >> Systems that do not run jails are not affected. >> >> The system administrator can do the following to load the default >> ruleset: >> >> /etc/rc.d/devfs onestart >> >> 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" > > I have always used the following rc.conf options to start jails: > > jail_xxx_devfs_enable="YES" > jail_xxx_devfs_ruleset="devfsrules_jail" > > If jail_xxx_devfs_enable is set to NO, would there be a problem? I > thought you always had to set jail_xxx_devfs_ruleset when enabling > devfs on jails. > > I think this has the same effect as the workaround above? Assuming the jail have no access to the device file system at all, you would not be affected by the problem. Setting jail_*_devfs_ruleset by itself is not sufficient because a recent change (only in 10.x) have removed the loading of default rules, making setting the rule set no-op. No, you don't have to set per-jail ruleset explicitly, the default is devfsrules_jail unless overridden. Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBCgAGBQJTYUToAAoJEJW2GBstM+nsnCEP/RnPDhR+QmvOhbdRwKeuDdcn SmcDtm+LmJSCxMfkVdDEuskQiI474xfrkGe6+6iIFkjilTU3/0xdKo4eIybp3ARd osYHJg9zUINIzHh2ez9CR+IqzYS/FD1jWMShhoB/qqWJayclXyz+HdfLCcryOQDn oYwneuYBRTKLSvViBAbq0pQmfzQX9mmeoSm8rR0lHuOdAfDTNyYKrod7Gku62BHL 2WZmXlgIFVsn+F3k0Ay2eG36D0ZxoAe/gQVhA3VAjSQXsgzWXmUccwpiPqK32mba gfRVfnC+ARdW0EQxWk258Z5oaAuLWXq2ntaVyr0RjODHXZr2Wi7nDRHSxczDGCrk yMSdcvHhSOx7dJxRkTashCS+5wwf2yPHChYI7t5XgO2aXukLlOTvM/HHKs0KZiyE MP1hNjujXu3t6JcIDLcuOogn2YrRYtkprphpjn0W3fN6dOjn2cyjn2o0fRoORerW ouqaunygcdCxWHUVWJeyql5aTPUJNMPEhkE/xIHNDtwlg9SNVUopMUsHzTN++yMB QEwMH91p4YaUnllW3u4At6WishkiwObIr6Ygtz7YvJja45F8g5ftRaOUdNNWONse WHDh/e0sxV6RIGr/yr28h2NVk2Kxqu7bP6XyVIV1F/qtuXkJPYyE5x9/DERreeYw 9sXDbKH7qzj/ANF4kUsY =bdkk -----END PGP SIGNATURE-----