Re: module's use of security_ops

chrisat_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.

> * 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.

> 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.

-chris

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