Re: module's use of security_ops

jmjonesat_private

> * jmjonesat_private (jmjonesat_private) wrote:
> > On Thu, 7 Jun 2001, Chris Wright wrote:
> >
> > No major objection, but could we preserve some of the "obscurity factor"
> > by creating a 
> > 
> > get_security_ops()
> > 
> > call, which passes to the module and could return -EPERM?  My thinking is:
> > 
> > * Drivers, etcetera, could access it if it was within module policy,
> 
> I assume "module policy" means an LSM policy.  How do you propose to
> identify the non-LSM module asking for the security_ops struct?  By
> module name...hi I'm the really safe 3c509 driver can I please have the
> security_ops?  This can be trivially forged.

Yes, "module" policy means LSM policy.

The identification needed may not be relevant at this time.  Pass a 
(char *) or, better, a (void *).  Drivers that NEED the security_ops
structure could fail if they don't meet whatever criterion there  is
in place.

Some security is usually better than none.

If you pass the whole filename to the LKM (from argv[0]) you allow 
the module to check the file directly, by md5check or any other 
method, BEFORE releasing the security_ops structure.  This is a 
very "heavy" solution, but one possible.

> 
> > * It reduces the exposure of the structure to areas of the kernel+modules 
> >   where it may not be necessary.
> > 
> > By exposing it entirely, you bypass the sanity and "locking" effects 
> > of the current code, don't you?  Also, exposing it globally allows a 
> > "bypass security crack" to live in ANY loadable entity, doesn't it?
> 
> No, by exporting the symbol you are not undermining organized access to
> the struct.  Anyone at anytime could start walking through the task list
> witout locking it and changing nice values, and pids, and uids, and...
> The kernel is functional not because there are things developers can't
> do, but things developers should do and have the tools to use (i.e. lock
> before accessing).  A module can scribble anything it wants anywhere.
> We can't stop this, and not exporting the security_ops struct looks like
> it actually impedes a non-lsm module from being able to _use_ the
> security provided by a lsm module.  This seems counter productive.

Okay, difference in terminology... you can access the structure directly
or via some calls, either way.  The DIFFICULTY in accessing the structure
is what concerns me.  A few lines of code, if it's exported vs. a long,
drawn out search.

Driver-modules come in from anywhere.  A diskette, the net, anywhere.
By imposing a restriction on whom can access security_ops, you have SOME
chance of intercepting "evil".

For example, I use FLASHPATH.O on my "favored" workstation so I can 
read and write smartmedia from my camera.  FLASHPATH.O has *NO* business
with security_ops.  If we make it HARD (in essence, eliminate the
possibility of a "legal" and "illegal" module by that filename), we
prevent "easy" cracks.  FlashPath.c comes down from the WEB (even worse
than the NET, security-wise).

A security module developer may keep a "remotely accessable" database of
md5checksums for "approved modules".

We already have some hooks in place that can support this "compound"
check.

Perhaps I'm suggesting central module registration on the LAN, the WAN, 
or in a local database.  Without a mechanism to DENY (dissuade?) access to
security_ops, none are possible.

My FLASHPATH driver could easily (a few lines) replace my whole security 
structure unless we hide it somehow.

> 
> > Yes, I have been told that "once you can install a module you're pretty 
> > much lost anyway", but a "policy" was in force that prevented it (one 
> > primary registration only) that is now lost.
> 
> Kernel deadlocks can be avoided by convention that is not strictly
> enforced.  For example, when acquiring two locks grab them in a
> consistent order.  This is not strictly enforceable...even if there is
> helpful function that always grabs the locks in the same order...a
> malicious or ill-informed developer could not use the helper function
> and grab the locks in what ever order they so feel.  Same goes here.
> This does not mean registration policies are lost...it just means that
> to be a good little lsm you have to play by the recommended rules.
> 

I'm not worried about "good little LSM's" but am worried about "bad little
LKM's"  I know I "champion Admins", but have been known to "install
things without deep analysis" many times.

J. Melvin Jones

|>------------------------------------------------------
||  J. MELVIN JONES            jmjonesat_private 
|>------------------------------------------------------
||  Microcomputer Systems Consultant  
||  Software Developer
||  Web Site Design, Hosting, and Administration
||  Network and Systems Administration
|>------------------------------------------------------
||  http://www.jmjones.com/
|>------------------------------------------------------

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