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
[EMAIL PROTECTED] 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 [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
