From owner-freebsd-security@FreeBSD.ORG Wed Apr 30 09:23: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 87DB447E for ; Wed, 30 Apr 2014 09:23:18 +0000 (UTC) Received: from mail1.canodus2.canodus.be (mail1.canodus2.canodus.be [83.149.89.9]) by mx1.freebsd.org (Postfix) with ESMTP id 35C69169B for ; Wed, 30 Apr 2014 09:23:18 +0000 (UTC) Received: by mail1.canodus2.canodus.be (Postfix, from userid 65534) id 45C6A32AD65; Wed, 30 Apr 2014 11:16:50 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on mail1.canodus2.canodus.be X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from [192.168.1.35] (d51532D1F.access.telenet.be [81.83.45.31]) by mail1.canodus2.canodus.be (Postfix) with ESMTPSA id C667E32AC39 for ; Wed, 30 Apr 2014 11:16:49 +0200 (CEST) Message-ID: <1398849409.4521.12.camel@debian.wout-t440s> Subject: Re: FreeBSD Security Advisory FreeBSD-SA-14:07.devfs From: Wout =?ISO-8859-1?Q?Decr=E9?= To: freebsd-security@freebsd.org Date: Wed, 30 Apr 2014 11:16:49 +0200 In-Reply-To: <201404300435.s3U4ZAfe093748@freefall.freebsd.org> References: <201404300435.s3U4ZAfe093748@freefall.freebsd.org> Organization: Canodus Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.8.5-2+b3 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list 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 09:23:18 -0000 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? > > V. Solution > > Perform one of the following: > > 1) Upgrade your vulnerable system to a supported FreeBSD stable or > release / security branch (releng) dated after the correction date. > > 2) To update your vulnerable system via a source code patch: > > The following patches have been verified to apply to the applicable > FreeBSD release branches. > > a) Download the relevant patch from the location below, and verify the > detached PGP signature using your PGP utility. > > # fetch http://security.FreeBSD.org/patches/SA-14:07/devfs.patch > # fetch http://security.FreeBSD.org/patches/SA-14:07/devfs.patch.asc > # gpg --verify devfs.patch.asc > > b) Execute the following commands as root: > > # cd /usr/src > # patch < /path/to/patch > # install -o root -g wheel -m 444 etc/defaults/rc.conf /etc/defaults/ > > Follow the steps described in the "Workaround" section, or reboot the > system. > > 3) To update your vulnerable system via a binary patch: > > Systems running a RELEASE version of FreeBSD on the i386 or amd64 > platforms can be updated via the freebsd-update(8) utility: > > # freebsd-update fetch > # freebsd-update install > > VI. Correction details > > The following list contains the correction revision numbers for each > affected branch. > > Branch/path Revision > ------------------------------------------------------------------------- > stable/10/ r265122 > releng/10.0/ r265124 > ------------------------------------------------------------------------- > > To see which files were modified by a particular revision, run the > following command, replacing NNNNNN with the revision number, on a > machine with Subversion installed: > > # svn diff -cNNNNNN --summarize svn://svn.freebsd.org/base > > Or visit the following URL, replacing NNNNNN with the revision number: > > > > VII. References > > > > The latest revision of this advisory is available at > > _______________________________________________ > freebsd-security-notifications@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-security-notifications > To unsubscribe, send any mail to "freebsd-security-notifications-unsubscribe@freebsd.org"