From owner-freebsd-arch Sun Jan 10 11:18:32 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA01753 for freebsd-arch-outgoing; Sun, 10 Jan 1999 11:18:32 -0800 (PST) (envelope-from owner-freebsd-arch@FreeBSD.ORG) Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA01746 for ; Sun, 10 Jan 1999 11:18:23 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.1a/8.9.1) with ESMTP id UAA29782 for ; Sun, 10 Jan 1999 20:17:48 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id UAA40212 for freebsd-arch@freebsd.org; Sun, 10 Jan 1999 20:17:48 +0100 (MET) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA21653 for ; Sun, 10 Jan 1999 10:19:34 -0800 (PST) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id OAA23107 for ; Sat, 9 Jan 1999 14:39:10 -0800 (PST) Received: from current1.whistle.com(207.76.205.22) via SMTP by alpo.whistle.com, id smtpdJ23105; Sat Jan 9 22:39:07 1999 Date: Sat, 9 Jan 1999 14:39:04 -0800 (PST) From: Julian Elischer To: arch@FreeBSD.ORG Subject: DEVFS Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Sorry if this is late, but I only discovered by accident that there had been a big discussion about DEVFS in the "arch" mailing list and it appears that my original subscription either failed or got clobbered.. Anyhow: >From what I gathered.. The point was raised that it's time for DEVFS to either be finished or be replaced by an equivalent item that is finished. Since the main part of DEVFS was ripped out by the throat by dk.com it has been waiting for me to either take it out or fix it again. It would be nice if we could agree on some things or at least discuss them. I have not given up on devfs, but I've been a bit dispirited by the lack of support. DEVFS is just fine as it is for non-disk devices, but it needs the SLICE code (or an equivalent) before it can really be useful. (more on this at the end). SLICE was waiting for CAM to come in so I could apply a bunch of changes that were CAM specific. It replaced the 'in-line' registration and probing of devices with a kernel daemon that managed all devices and did these things in a way that allowed a context to be associated with the IOs. This simplified a lot of things. It was also needed for devices (such as CAM supplies) that have arrival and departure events. OK, so assuming that DEVFS gets rev'd to the next version or even replaced, here are some things to think about: 1/ Every driver needs to add it's entries.. What I have added to each driver would probably do or be close, for almost any devfs implementation with maybe minor mods. There are only so many things you can need to provide.. 2/ The filesystem needs to be able to create multiple instances of itself for chroot systems etc. 3/ The filesystem needs to give a method to allow new devices to appear as created. If the layout of a /chroot/dev filesystem has been changed, then you need to work out WHERE in the filesystem to create the new device. 4/ If a user changes the name of a device or makes a link to it, those devices must still be removed when the device becomes invalid. 5/ If a device has its modification time changed, does that change reflect through all instances of that device? (E.g. /dev/xxx and /chroot/dev/xxx). What about permissions? What about ownerships? 6/ If a process has a device open and it 'goes away', what should happen? 7/ Persistence is I think a WOFTAM. Some people want it. It could be ignored in my opinion but you should at least have a scheme in mind.. My suggestion is to pick up permissions and owners from inodes of the same name read from the filesystem on which the devfs was mounted. A synthetic / filesystem (An idea that I know Poul has been kicking around for a while) wouldn't be able to do that, but there are other ideas I guess. 8/ There should eventually be built in, a way of getting directly from the DEVFS entry to the driver. The present DEVFS bypasses the bdevsw table, but still goes via the devsw entry itself. This may be acceptable. We might as well get the requirements worked out. After all we have a couple of years of experience with this now.. The reason for the SLICE module comes from the need to be able to support hierarchically organized structures of 'disklike' devices. Disklike devices include parts of disks and concatenations in various manners of disks. They also include 'value-added devices" such as a layer that lies above a disk and remaps bad blocks, or, possibly supplies a service such as encryption. The present system relies upon the 'open' code to force a scan of the disk devices and thus cannot supply the subdevices until they are opened. A chicken/egg problem. There is a hack that works for the root disk, and disks present at boot, but doesn't generalize. The present system is also "locked" into handling only the three formats "raw disk, fdisk, and disklabel". Extending it to handle CD-ROM partitions and Macintosh partitions would be a major rewrite. This suggests that the present system needs either a radical update or replacement. If we need to rewrite it anyhow for production of subdevices as the device 'arrives' then we might as well generalize it to be able to support arbitrary 'organizing layers'. Thus SLICE was born. DEVFS doesn't really need it, but the rest of the system needs it to be able to use DEVFS correctly. As it's totally dynamic, it of course needs DEVFS because a repartition of the disk may mean the need to produce new device nodes. The reason for DEVFS is that it is dynamic, and allows for a totally dynamic kernel. These "disk-like devices" are also dynamic and there is really no good way of representing the many combinations that can be produced in a static system (such as the present major/minor system). Personally, I'd much rather work WITH someone on DEVFS, but so far there has been a lot of criticism and no help. Interestingly, the LINUX devfs is already at the stage that ours is, but is similarly stopped at the point of needing something like SLICE. Their disk system, however, is not hierarchical in the manner that ours might be so, they don't see the need to support hierarchies of formats (e.g. vinum on partitions of slices). Anyway I hope we can have some discussion on what a devfs should achieve, and then we can see if the present system can do it or maybe it needs a complete rewrite. My main aim is to make FreeBSD be more dynamic and less static. If someone else sees a better way of doing this then that's OK by me. BTW: What happened to Poul's work to remove block devices entirely? Julian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jan 10 14:11:04 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA20660 for freebsd-arch-outgoing; Sun, 10 Jan 1999 14:11:04 -0800 (PST) (envelope-from owner-freebsd-arch@FreeBSD.ORG) Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA20650 for ; Sun, 10 Jan 1999 14:10:59 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.1a/8.9.1) with ESMTP id XAA02162 for ; Sun, 10 Jan 1999 23:10:11 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id XAA41490 for freebsd-arch@freebsd.org; Sun, 10 Jan 1999 23:10:10 +0100 (MET) Received: from octopus.originative.co.uk (originat.demon.co.uk [158.152.220.9]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA13455 for ; Sun, 10 Jan 1999 13:06:01 -0800 (PST) (envelope-from paul@originative.co.uk) Received: by OCTOPUS with Internet Mail Service (5.5.1960.3) id ; Sun, 10 Jan 1999 21:04:16 -0000 Message-ID: From: Paul Richards X-To: "'Poul-Henning Kamp'" To: freebsd-arch@FreeBSD.ORG Subject: RE: DEVFS, the time has come... Date: Sun, 10 Jan 1999 21:04:15 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Poul-Henning Kamp writes: > Paul Richards writes: >> I think first of all that it's worth clarifying that *everyone" is >> in favour of persistence. No-one is advocating that policy should >> not be defined by the admin. > > Clearly you're not even trying to use the same terminology as us here. > > No, there is not unanimous support for persistence ( which means that > a random "chmod 654 /dev/foo" is persistant forever) > > There >IS< agreement that security must not be worse and that the > admin should be left in control. > >> The discussion is and should centre on how local policy is >> implemented, should it be done in the kernel or in userland. > > It is also obvious that you're not reading the thread either. I've read the thread very carefully. I don't think people have seriously asked themselves whether a "random chmod" should persist across reboots largely because "random chmods" just don't happen. The point I was emphasising is that everyone expects policy changes to be persistent, if you're doing a chmod it's to change policy. It's clear therefore that everyone is in favour of persistence and all we're discussing here is how best to implement it. Your example of a "random chmod" has actually made it clear to me how confusing a non-persistent solution could become since policy would be determined in two places. Default policy would be determined by the boot settings whereas a transient policy could be implemented by changes to perms in devfs. If policy is being tweaked in devfs but the default policy is not updated to match when the new policy has been satisfactorily determined then at reboot the old policy would be implemented. This is clearly going to lead to confusion as well as lowering security e.g. you add a new device, you set the perms using chmod on devfs to suit security at your local site, you then reboot and you lose your setup possibly opening up a security hole on the new device. The complication is that policy is maintained in two places, I think this should be avoided at all costs. Either a chmod should transparently update the persistent policy or policy should be set using some other mechanism that ensures integrity. > Persistence can be done in a daemon, probably better and certainly > less error prone than in the kernel. Consequently the kernel part > will be just the bare bones needed, and everything else (policy > or persistence or both) will be done in a device-daemon. > > >I'd like to hear good arguments against putting persistence into the > >kernel since the userland solutions all have shortcomings that we're > >fighting to cludge around and will almost certainly need some kernel > >support in any case. None of the following are very good points against a kernel implementation. > > 1. It can be done in userland, there is no performance requirement > to put it in the kernel. I disagree, the performance requirement is to remove any risk of a race condition whereby a device can appear without policy being applied. > 2. You can't do it without a lot of kludging around in the kernel > either. A question of implementation, I thought we were not going to pursue implementation issues until the concepts had been resolved. As I said though, I'm not necessarily advocating that policy should be determined by file perms, there are other ways of determining policy that may result in cleaner implementations of policy persistence. > > 3. Picobsd and other groups of people want small kernels. Not relevant, you're assuming a) that there would be a great deal of kernel bloat b) that kernel size is the only issue, if you need a userland daemon to implement a devfs then that constitutes bloat as well for small systems. > 4. Doing it in a daemon makes it possible for people to choose what > they want. (you obviously don't want persistence on a chroot > partition.) So does doing it in the kernel, possibly more so since it could easily be a mount option. > Paul: please read the entire thread before you jump in. You > applicable comments will be most welcome. Poul, I've read *every* message in great detail and repeatedly accusing me of not doing so in your reply does little to forward the discussion. I raised some perfectly valid concerns regarding an userland implementation that you have ignored in your reply, i.e. can we guarantee that the race condition that exists between device instantiation and the implementation of policy doesn't open up a potential security hole and whether a solution based on daemon is robust or not. Paul. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jan 10 16:42:24 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA07315 for freebsd-arch-outgoing; Sun, 10 Jan 1999 16:42:24 -0800 (PST) (envelope-from owner-freebsd-arch@FreeBSD.ORG) Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA07309 for ; Sun, 10 Jan 1999 16:42:21 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.1a/8.9.1) with ESMTP id BAA04119 for ; Mon, 11 Jan 1999 01:41:44 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id BAA42734 for freebsd-arch@freebsd.org; Mon, 11 Jan 1999 01:41:44 +0100 (MET) Received: from pluto.plutotech.com (mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA18753 for ; Sat, 9 Jan 1999 13:40:31 -0800 (PST) (envelope-from gibbs@plutotech.com) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.9.1/8.9.1) with ESMTP id OAA20702; Sat, 9 Jan 1999 14:39:57 -0700 (MST) (envelope-from gibbs@plutotech.com) Message-Id: <199901092139.OAA20702@pluto.plutotech.com> X-Mailer: exmh version 2.0.2 2/24/98 X-To: Paul Richards To: freebsd-arch@FreeBSD.ORG Subject: Re: DEVFS, the time has come... In-reply-to: Your message of "Wed, 06 Jan 1999 16:31:16 GMT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 09 Jan 1999 14:31:50 -0700 From: "Justin T. Gibbs" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > 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 From owner-freebsd-arch Sun Jan 10 16:46:19 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA07627 for freebsd-arch-outgoing; Sun, 10 Jan 1999 16:46:19 -0800 (PST) (envelope-from owner-freebsd-arch@FreeBSD.ORG) Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA07622 for ; Sun, 10 Jan 1999 16:46:16 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.1a/8.9.1) with ESMTP id BAA04178 for ; Mon, 11 Jan 1999 01:45:42 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id BAA42772 for freebsd-arch@freebsd.org; Mon, 11 Jan 1999 01:45:42 +0100 (MET) Received: from pluto.plutotech.com (mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA20345 for ; Sat, 9 Jan 1999 13:55:11 -0800 (PST) (envelope-from gibbs@plutotech.com) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.9.1/8.9.1) with ESMTP id OAA20842; Sat, 9 Jan 1999 14:50:37 -0700 (MST) (envelope-from gibbs@plutotech.com) Message-Id: <199901092150.OAA20842@pluto.plutotech.com> X-Mailer: exmh version 2.0.2 2/24/98 X-To: Poul-Henning Kamp To: freebsd-arch@FreeBSD.ORG Subject: Re: Implementing a DEVFS daemon In-reply-to: Your message of "Wed, 06 Jan 1999 19:45:36 +0100." <25286.915648336@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 09 Jan 1999 14:42:30 -0700 From: "Justin T. Gibbs" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I think this can only be solved by using the classical "kill -1" > strategy for rereading config files. > > But wait! It gets worse: If devd uses a plain chown(2) to apply the > policy, > [Upcall version:] devfs will notice that somebody changed a device > owner and inform devd which will need to realize that this > modification was one it did itself. > [devd poll version:] devd will encounter the changed modes on the next > scan and have to figure out that the change was not one done "by > hand", but merely its own application of the policy. The notification causes a comparison between currently visible policy and stored policy. If the policies match, there is nothing to do. I don't see this as much of a special case. > JMB said: >> The timing issues seem to be ugly to me. It would be nice if >> shutdown forced this daemon to roam over the /devfs tree. It almost >> sounds like we need upcalls from the kernel to the daemon -- at >> which point I wonder why the daemon is not in the kernel. I still >> have to read 99% of the kernel, so if this is wacky tell me and I'll >> shut up. This problem isn't too hard to solve. Devd re-mounts all devfs instances R/O, takes a last snapshot, then exits. > Upcalls will be needed if we decide to tackle PnP/USB and so on, > but belive me, it is still at lot less ugly than to implement the > devd in the kernel. You wouldn't need upcalls if all PnP/USB devices instantiated DEVFS nodes upon arrival/departure events. Then the only thing you need is a way to notice changes in a directory which should be possible to do with an enhanced poll(2). If you don't like this, you could also trigger events off of the modification time of '/dev/PnP' or '/dev/USB' that caused reconfiguration of those types of devices, but this seems less elegant than the file per device paradigm. -- Justin [In a followup series of short mails, phk+gibbs notes that we also may need to be able to modify configuration of the system depending on what is available at just that time - e.g, use DHCP when pccard is available, and that this may need notifications. -EE] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jan 10 16:54:18 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA08302 for freebsd-arch-outgoing; Sun, 10 Jan 1999 16:54:18 -0800 (PST) (envelope-from owner-freebsd-arch@FreeBSD.ORG) Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA08293 for ; Sun, 10 Jan 1999 16:54:14 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.1a/8.9.1) with ESMTP id BAA04245 for ; Mon, 11 Jan 1999 01:53:41 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id BAA42818 for freebsd-arch@freebsd.org; Mon, 11 Jan 1999 01:53:41 +0100 (MET) Received: from octopus.originative.co.uk (originat.demon.co.uk [158.152.220.9]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA04335 for ; Sun, 10 Jan 1999 16:05:53 -0800 (PST) (envelope-from paul@originative.co.uk) Received: by OCTOPUS with Internet Mail Service (5.5.1960.3) id ; Mon, 11 Jan 1999 00:04:05 -0000 Message-ID: From: Paul Richards X-To: "'Justin T. Gibbs'" To: freebsd-arch@FreeBSD.ORG Subject: RE: DEVFS, the time has come... Date: Mon, 11 Jan 1999 00:04:04 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Justin T. Gibbs writes: > 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. I'd live with this situation but I still have reservations about a daemon based solution. >> 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. If the daemon stops running for whatever reason then the admin might not even realise it and be totally unaware that the policy changes will not be applied upon reboot. A reboot may be many months away by which time the policy change may have been completely forgotten about. This is a good example of why I think the timing issues of applying the policy change and having them become persistent are important to iron out. I think POLA requires that a policy change be implemented forever more once it is carried out and there be no risk that for some reason it does not "stick". To be honest, I'd rather there be no persistence at all so that at least people are aware of the issues than have a persistence mechanism that has a possibility of failure. I have definite reservations about a solution that relies on some agent to sync up persistent policy with current state since if that sync up doesn't occur security holes will crop up. >> 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. That's probably the question we should have asked ourselves in the first place :-) I'm not advocating a solution that maintains the current mechanisms of stating policy, i.e. I'm not a slave to POLA, if a totally new methodology seems appropriate I think we should adopt it, in that case POLA doesn't apply, it only applies when things seem the same but are subtly different i.e. if it looks like /dev and chmod etc work then it'd better work exactly as before. On the other hand, if we simply stop using those mechanisms (chmod of files in /dev) for maintaining policy and require a totally different mechanism to be adopted it doesn't break POLA. What I'm suggesting is that we make /dev a static view of the kernel device information and maintain that information via a totally different means. That way there is a single source of policy rather than a transient source (current state of dev) and a persistent source (some file maintained by a daemon/user). Until a moment ago I was thinking that this would need a kernel based database of device information since device events occur in the kernel but it's just occurred to me that that doesn't have to be the case. If we accept my opinion above, that /dev should be a static view and not a control mechanism then we could enforce policy completely in userland by not having the kernel drive events but only do the notification. For instance: At the moment the model we have is that devfs creates the view as the device comes into existence and thereafter doesn't have any involvement. Any changes to /dev by the user after this event are done through the filesystem using chmod etc and need to be recorded to achieve persistence and replayed after the next reboot. A totally different idea would be to limit kernel functionality to issuing an event to a user process to signify the arrival of a device and then leave the userland daemon decide what to do. It can look up a database and based on that determine which instances of devfs will want to see this new device and what name to use to create it as, even whether links should be setup. Then it can issue a syscall to create the devices. Admin can be done with another syscall to change device parameters. If a device goes away then I think the kernel should do any clean up rather than passing an event to the daemon since I can't see how the daemon could do anything about other processes that have the device open. The kernel should probably force a close and userland code would need to be cleaned up to deal with the possibility of devices going away. This would seem to satisfy a number of criteria from all sides. Advantages: The kernel implementation is minimal, passing an event to userland for arrival of a new device. A syscall to create a device in devfs, a syscall to change the properties of a device. There'd be no need to store any information at all about policy in the kernel. Policy changes are user driven and instantaneous, rather than kernel driven or reliant on some user process providing synchronisation. There'd be no race conditions due to the kernel acting on events and the userland code trying to catch up. It would be trivial to build user tools to control devices since syscalls would exist for easy manipulation. It would make developing graphical admin tools etc much easier. Another advantage of the filesystem as a static view methodology is that devices can't be accidentally screwed by filesystem cockups i.e. a lame admin doing a rm -fr in the wrong place can't harm the device view, similarly for related filesystem accidents. These things do happen, protecting the system from mistakes is a good thing IMO. To change device policy you'd have to consciously make the effort to change the policy source. If the daemon should die, you could still use a device control program to change policy in a safe and consistent manner without having to worry about fixing things up at a later reboot of ensuring consistency of information in more than one source, which you would have to do with a filesystem based policy method i.e. do the chmod then remember to update the policy database so it happens after reboot. Disadvantages: A totally new way of implementing policy would be needed from admins since manipulating the filesystem view of devices would no longer be possible. Maybe this is a bit radical but it seems like a neat solution to the problems. Paul. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message