Subject: Re: LKM support
To: Bill Studenmund <email@example.com>
From: Michael Graff <firstname.lastname@example.org>
Date: 11/08/1996 15:03:26
Bill Studenmund <email@example.com> writes:
> > I was going to suggest the following for this sort of thing:
> > (1) a command, run at securelevel 0, which does an md5 hash and remembers
> > the size and name of an LKM, and gives this to the kernel.
> > (2) a userland daemon. If you want dynamic loading, you run this.
> > (3) a command to load a module which was previously identified in the
> > kernel.
> > This would more or less remove security holes from the LKM loading after
> > securelevel 0 is gone part I believe.
> This idea sounds quite workable. I think you're right about closing
> security holes. Would it be reasonable to support multiple versions of the
> same module? The idea would be to support testing of a new module in a
> "real" environment.
Sure. Just register both at securelevel 0 and load the non-default
one by hand before use.
Also, it was pointed out after talking to a coworker that remembering
the exact state of the inode might be good enough. That would remove the
need for MD5 in the kernel, although I can see a use for MD5 in other things
as well, like tcp sequence numbers...