Date: Wed, 7 Jun 2000 08:07:07 -0400 (EDT) From: Robert Watson <rwatson@FreeBSD.ORG> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: Bjoern Fischer <bfischer@Techfak.Uni-Bielefeld.DE>, hackers@FreeBSD.ORG Subject: Re: kerneld for FreeBSD Message-ID: <Pine.NEB.3.96L.1000607075658.25263A-100000@fledge.watson.org> In-Reply-To: <200006070728.AAA97354@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 7 Jun 2000, Matthew Dillon wrote: > I personally consider leaving the kernel module loadable intact after > boot to be a huge, huge security hole. Loadable modules... fine, but > once the machine goes multi-user I want to up the securelevel and > that disables any further kld operations. If one of the biggest > advantages of FreeBSD is its robustness and reliability, then one > generally does not want to go loading and unloading modules all the > time. I think that's unrealistic for end-user machines. In a world of removable PCcards, USB devices, etc, expecting that the GENERIC kernel include code for all of them leaves us in a fairly unscalable place. As the rest of the world moves towards not requiring a recompile to add a more obscure ethernet card, we should not be moving in the opposite direction. Don't get me wrong -- I'm all for a more secure system, but securelevels don't really solve the problem, and can't address the type of issue you describe. If you take a look at Tim Fraser's lomac paper from the recent Oakland conference, it strongly suggests that a traditional MAC policy can (with a high degree of compatibility) provide exactly the kind of protection that securelevels can not :-). The recent POSIX.1e-related capability interfaces have been added so that those working on support for MAC models on FreeBSD can rely on them. As such, there is substantial hope (and intent) that similar MAC models (Biba, MLS) will be available on FreeBSD in the near future. > A 'kerneld' like gizmo for FreeBSD would be a waste of time. The > scheme we have now -- having the utility programs load the modules > on the fly (ifconfig, vnconfig, etc...) works wonderfully. I tend to agree, on face value, with an intuitive objection to kerneld. That said, it should be observed that a "kerneld" would restrict the code sufficiently privileged to cause a module load in one binary, as opposed to a model where that type of privilege has to be provided to hundreds of them (even huge beasts like ppp). If requests for kernel functionality loads come through a well-audited (both senses) and well-defined LPC mechanism, there is substantially less risk involved. In a world where dynamic kernel module loading occurs even after entering secure, multi-level operation, that type of protection seems like a good idea. It would allow us to distinguish the following privileges: 1 Right to request specific functionality be loaded 2 Right to load the functionality 3 Right to invoke the functionality Letting, say, ppp have (1) and (3) but not (2) provides a substantial security improvement, while retaining the ability to introduce new functionality at run-time. And in a sense, we already have two kerneld's -- pccardd and usbd, which maintain mappings between named devices and drivers, etc. Combining them, and adding another source of requests (and LPC channel over a UNIX domain socket) would not be that hard. Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1000607075658.25263A-100000>