Re: Extending a Security Module

From: Chris Wright (chrisat_private)
Date: Mon May 21 2001 - 17:02:03 PDT

  • Next message: jmjonesat_private: "Re: Extending a Security Module"

    * jmjonesat_private (jmjonesat_private) wrote:
    > Would a 
    > struct security_ops * get_security(something);
    > function that somehow allows a "stacked" module to access
    > the global pointer WITH PERMISSION of the installed module
    > be ridiculously unsafe?  Or should modules that wish to be 
    > "extensible" provide their own interface?
    It is sketchy to allow access to this structure.  What stops someone from
    loading a module that calls get_security and then starts overwriting the
    function pointers?  To date we have considered mixing modules largely
    > Or is the security_ops structure TRULY globally accessable...
    > and if so... isn't that a risk?
    The security_ops structure is not an exported symbol.  It would be a risk if
    any module could simply overwrite the security_ops structure.
    > I think this topic has been visitted before, but are you 
    > sure this shouldn't be provided?  I ask because my "silly"
    > LSM design could use it to great advantage.
    As an interim workaround, the capability_ops structure _is_ exported.  Yes,
    this is a risk.  I think Greg meant to export it in general, but when I
    looked at it, it only gets exported if the capability_plug is compiled in to
    the kernel (or compiled as a module and loaded in to the kernel).  So you
    have to load the capability_plug and then mess with it's table of function
    pointers (this is sub-optimal, but we have not been encouraging mixing
    security modules).  I wouldn't really recommend doing this (definitely do
    _not_ rely on it, as it is guaranteed to change).
    linux-security-module mailing list

    This archive was generated by hypermail 2b30 : Mon May 21 2001 - 17:04:35 PDT