Date: Sun, 10 Jan 1999 21:04:15 -0000 From: Paul Richards <paul@originative.co.uk> To: freebsd-arch@FreeBSD.ORG Subject: RE: DEVFS, the time has come... Message-ID: <E40CBF0361C7D111914000C0F0303D108861@OCTOPUS>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E40CBF0361C7D111914000C0F0303D108861>