Re: module's use of security_ops

crispinat_private

jmjonesat_private wrote:

> On Fri, 8 Jun 2001, Stephen Smalley wrote:
> > > 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.
> > As others have already said, this doesn't introduce any new
> > vulnerabilities.
>
> But it  DOES simplify the exploitation of a vulnerability.  I've already
> "signed off" on this, but feel compelled to point out that exposing the
> security_ops structure DOES simplify any LKM's task if the code intends
> to "short circuit" security, even if only marginally.

Go read Saltzer & Schroeder 1974
http://web.mit.edu/Saltzer/www/publications/protection/index.html It is the Holy
Bible of system security.  Among other pearls of wisdom in that paper, they
explain that an obscurity defense such as the one described above is of
absolutely no *security* value.  Malicious code prepared by an attacker doesn't
care how inconvenient it is to access a critical data structure; they will just
do it.

The only purpose to the export/not-export decision is the "data hiding"
abstraction for software engineering purposes.  It is not a security issue.

In general, all Linux loadable module code must be 100% trusted.  Linux is not a
microkernel, there is no protection barrier between modules and the rest of the
kernel, and so your entire machine is completely at the mercy of module code.
Whether module code is trust *worthy* is entirely another matter, and in some
cases, the code is not trust worthy.  Never the less, as soon as you load a
module, you are trusting it 100%.

If that's not good enough, go play with OS X :-)  OS X is Mac OS laid on top of
BSD laid on top of the Mach microkernel.  I'm not sure how much practical access
you get to the microkernel, but at least it has one.

For more practical microkernel applications, QNX is a very nice, very high
performance, very stable microkernel.  Brilliant architecture, with a very
transparent distributed computing model. QNX has an excellent pedigree (a couple
of begots from David Cheriton's PhD thesis on the Thoth microkernel, which begot
the V kernel).  But QNX is not Linux, is not UNIX, and is not Free Software.

Crispin

--
Crispin Cowan, Ph.D.
Chief Scientist, WireX Communications, Inc. http://wirex.com
Security Hardened Linux Distribution:       http://immunix.org
Available for purchase: http://wirex.com/Products/Immunix/purchase.html

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