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 _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "[email protected]"
