Date: Fri, 02 May 2014 10:09:22 +0200 From: Wout =?ISO-8859-1?Q?Decr=E9?= <wout@canodus.be> To: d@delphij.net Cc: freebsd-security@freebsd.org Subject: Re: FreeBSD Security Advisory FreeBSD-SA-14:07.devfs Message-ID: <1399018162.3822.1.camel@debian.wout-t440s> In-Reply-To: <536144E8.4020502@delphij.net> References: <201404300435.s3U4ZAfe093748@freefall.freebsd.org> <1398849409.4521.12.camel@debian.wout-t440s> <536144E8.4020502@delphij.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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 > >> <URL:http://security.FreeBSD.org/>. > >> > >> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1399018162.3822.1.camel>