From owner-freebsd-security@FreeBSD.ORG Fri May 2 08:09:32 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 1A032B9F for ; Fri, 2 May 2014 08:09:32 +0000 (UTC) Received: from mail1.canodus2.canodus.be (mail1.canodus2.canodus.be [83.149.89.9]) by mx1.freebsd.org (Postfix) with ESMTP id A7B6117A6 for ; Fri, 2 May 2014 08:09:31 +0000 (UTC) Received: by mail1.canodus2.canodus.be (Postfix, from userid 65534) id 90B0E32AD87; Fri, 2 May 2014 10:09:22 +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.102] (94-225-247-220.access.telenet.be [94.225.247.220]) by mail1.canodus2.canodus.be (Postfix) with ESMTPSA id 4E66132AC66; Fri, 2 May 2014 10:09:22 +0200 (CEST) Message-ID: <1399018162.3822.1.camel@debian.wout-t440s> Subject: Re: FreeBSD Security Advisory FreeBSD-SA-14:07.devfs From: Wout =?ISO-8859-1?Q?Decr=E9?= To: d@delphij.net Date: Fri, 02 May 2014 10:09:22 +0200 In-Reply-To: <536144E8.4020502@delphij.net> References: <201404300435.s3U4ZAfe093748@freefall.freebsd.org> <1398849409.4521.12.camel@debian.wout-t440s> <536144E8.4020502@delphij.net> Organization: Canodus Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.8.5-2+b3 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Cc: freebsd-security@freebsd.org 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: Fri, 02 May 2014 08:09:32 -0000 On Wed, 2014-04-30 at 11:46 -0700, Xin Li wrote: > 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, Ok, thanks for clarifying that! Cheers