Date: Sat, 09 Jan 1999 14:31:50 -0700 From: "Justin T. Gibbs" <gibbs@plutotech.com> To: freebsd-arch@FreeBSD.ORG Subject: Re: DEVFS, the time has come... Message-ID: <199901092139.OAA20702@pluto.plutotech.com> In-Reply-To: Your message of "Wed, 06 Jan 1999 16:31:16 GMT." <E40CBF0361C7D111914000C0F0303D108859@OCTOPUS>
next in thread | previous in thread | raw e-mail | index | archive | help
> I'll focus on my concerns for a daemon based solution. ... > If devices are created with default perms (possibly based on class) > then there is a clear race condition between the device coming into > existence and the daemon running. This may or may not provide the > potential for a security breach. To safeguard against this > possibility the alternative is to create the device with 000 perms > so that no possibility of a security hole exists. However, this > creates a chicken/egg situation at boot since the root filesystem > would need to be accessible by root or you're not going to get very > far. Permissions are not a problem: Script started on Sat Jan 9 14:10:19 1999 You have mail. # df Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/da0s2a 31743 26514 2690 91% / /dev/da0s2e 98479 28280 62321 31% /var /dev/da0s2f 695311 543183 96504 85% /usr /dev/da0s2g 1849623 1673301 28353 98% /a procfs 4 4 0 100% /proc /dev/da1s1a 4425736 1279448 2792232 31% /c # umount /c # chmod 000 /dev/da1s1a # ls -l /dev/da1s1a b--------- 1 root wheel 4, 0x00020008 Sep 4 1997 /dev/da1s1a # mount /c # df Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/da0s2a 31743 26514 2690 91% / /dev/da0s2e 98479 28280 62321 31% /var /dev/da0s2f 695311 543183 96504 85% /usr /dev/da0s2g 1849623 1673301 28353 98% /a procfs 4 4 0 100% /proc /dev/da1s1a 4425736 1279448 2792232 31% /c # exit Script done on Sat Jan 9 14:10:44 1999 There is a chicken and egg problem with DEVFS and mounting root that Julian alluded to some time back having to do, I believe, with needing access to DEVFS before root is mounted, but this is a solvable problem. If you agree that creating the nodes 000 and possibly even in the whiteout state is sufficient to safeguard the system, then there is no exploitable race. > From a robustness point of view, I'd be very concerned about > relying on a userland process for maintaining /dev. If that daemon > should not start or at some later point fall over then you may find > you have a hard time getting a useable system. If the daemon doesn't start, you'll find yourself in single user mode and can use chmod/chown to manually arrive at a usable system. If the daemon dies after performing initial configuration, the worst case scenario is that persistence of chown/chgrp/etc. operations will be lost with a reboot and that you will have to perform manual operations for non-root users to see dynamic devices that have arrived after devd's death. This does not seem unacceptable for a pathological situation. > As a worst case scenario, should the on-disk copy of the image get > damaged in any way then at next boot you'll have a totally screwed > system, this is true of other binaries as well of course but I think > we should minimise such dependencies not increase them. If we become really worried about these recovery scenarios, we can ship a modified MAKEDEV that can be run to provide standard permissions on extant nodes. This should make it quite easy to get the system up far enough to restore or rebuild a working binary. > Personally, I can't see any way of preventing race conditions > without applying policy when the device is created and that will > require a kernel implementation of persistence. Before attempting to push a kernel implementation, please define the kinds of persistent information that can be recorded. How much kernel bloat will it take to be able to specify policy for ranges of non-existent devices and how do you specify this policy? I would want the full flexibility of regular expression matching to specify policy for dynamic devices. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199901092139.OAA20702>