Re: module's use of security_ops

jmjonesat_private

On Fri, 8 Jun 2001 sarnoldat_private wrote:

> On Fri, Jun 08, 2001 at 10:57:48AM -0400, jmjonesat_private wrote:
> >    a global variable KERNELSECURITY in the "manner" of errno without
> >    passing anything?
> 
> Absolutely not. :)
> 
> Think "SMP" and I think you will agree that this global value is
> probably not a wise move. :) (The problem continues to exist even on
> monoproc machines, but not as obviously broken.)

Acknowleged.  I can't get SMP into my brain for some reason, although, 
there are "workarounds".

> 
> > 5)  For GODESSES'S SAKE, protect security_ops SOMEHOW, or this API is only 
> >     e pluribus unum and vulnerable to "total replacement" from ANYWHERE
> >     in kernel space. Provide a "non-functional copy", provide a module
> >     check for revelation, SOMETHING.  The idea of a global export just 
> >     seems to introduce too many new vulnerabilities.
> 
> I understand your concern. However, recall that this is the kernel
> we are talking about; any code loaded into the kernel is completely
> trusted. The assumption is made that kernel code is infallible and has
> no malicious purpose.
> 

Since modules of any kind can be "insmod'd" into the kernel by the admin,
"total trust" is a pretty liberal policy.

> Not exporting the security_ops structure is only an obscurity defense
> against code that is already assumed to do no harm. If there is kernel
> code you don't trust, either #ifdef it out, or refuse to load the
> module (if it comes in that form).
> 

Okay (sigh).  I think that assumption is unsupportable, but your
conclusion follows if the assumption is true.

How do I refuse a module loading without knowing if it needs
security_ops, in a general sense?  Even minimally, exporting does 
not leave an audit trail...

> Or, run a microkernel you do trust. :)
> 

You throwing me out of Linux altogether? (^_^)

I like microkernels, but there's no one (yet) that works as well as 
Linux.  Period.

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

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