Re: Binary only module overview

sarnoldat_private

On Mon, Sep 24, 2001 at 05:16:20PM -0700, Greg KH wrote:
> permission() is in fs/namei.c.  How are you going to modify that in a
> loadable module?  You would have to modify fs/namei.c, and if you do
> that, you have to publish your changes.

Straying offtopic here...

grep permission /proc/ksyms # and make note of the address
open("/dev/kmem");
llseek(/* address from above */);
write(/* new permission code */);

Of course, if one's permission code is longer than the original
permission code, one must make the 'new permission code' a simple jump
to the location of the real new permission code -- which can be found at
module load time.

Repeat for all kernel symbols exported through /proc/ksyms.

Right? And this is perfectly legal under the GPL, because it is
exploiting the user interfaces of syscalls (and I'm hoping /proc/ and
sysctl are included in the GPL-exempt list :) .

While it might even be a fair amount of work to get something like this
to work, I am fairly certain that this approach, taken iteratively,
would allow for re-writing large pieces of the kernel. And, once someone
has decided upon this iterative approach anyway, I'm sure some tools
could be written to help automate the task.

The LSM interface is fairly similar -- sure, it *could* be used to
redefine large chunks of the kernel, but it would be difficult. (Not as
tough as that previous example, but beyond the trivial stage, in any
case.) I think it would be safe to say that the clear majority of
software that would use the LSM API would wind up being security
modules, if only because writing 'other' things would be an awful lot of
work.

Given that, I can't see any reasons to forbid binary modules. Some
groups will require binary-only security modules. Why not take the
Debian policy, and try to make it work for those people?[1]

I tend to think that the Free Market system of selecting security
modules will reward and punish module creators based on the relative
merits and demerits of their modules -- which include the licensing. If
enough people don't like binary only modules, companies that provide
modules only under binary-only licenses will quickly learn the error of
their ways, as people flock to the free ones. However, if people can see
the value offered by a binary-only module (note how popular Microsoft
remains), perhaps companies that offer binary-only modules won't suffer.

I don't see why the LSM interface should decide what business model
companies should use, when the Linux user community can do the job just
as well..

[1]: http://www.debian.org/social_contract 

_______________________________________________
linux-security-module mailing list
linux-security-moduleat_private
http://mail.wirex.com/mailman/listinfo/linux-security-module