Re: [RFC][PATCH] Add LSM sysctl hook to 2.5.59

From: Stephen D. Smalley (sdsat_private)
Date: Tue Jan 21 2003 - 07:32:55 PST

  • Next message: Stephen D. Smalley: "Re: [RFC][PATCH] Add LSM sysctl hook to 2.5.59"

    Crispin Cowan wrote:
    > Christoph's objection is that each module would have to list all the 
    > sysctl variables. Can the hook be modified so that a module need only 
    > decide whether or not the subject process can call sysctl?
    A security module writer can use the existing sysctl hook in this
    manner (i.e. purely process-based restrictions) as well as in a
    finer-grained manner (i.e. distinguishing individual sysctl
    variables).  The hook provides the full range of flexibility to the
    module writer.  And, of course, the module writer can not implement
    the hook at all if no restrictions are desired beyond the DAC logic.
    Also, note that Christoph's objection was to having to list all of the
    _sensitive_ sysctl variables, not listing all the sysctl variables.
    Even SELinux does not list ALL of the sysctl variables; we group most
    of them into equivalence classes based on the sysctl hierarchy and only
    individually identify a few highly sensitive variables.  Christoph's
    concern is that identifying that set of highly sensitive variables is
    tightly coupled to the particular kernel and should not be duplicated
    among the various security modules.  I agree that it would be nice if
    the kernel provided a hint regarding its view of the sensitivity of a
    sysctl variable, but a particular security module might have a
    different view (and how it chooses to protect that variable may vary
    widely depending on the security model and attributes that it implements).
    Hence, you would still want the hook, and the hint would simply become
    part of the ctl_table state that is already passed to the hook.  No
    change required to the hook interface itself.
    Stephen Smalley, NSA
    linux-security-module mailing list

    This archive was generated by hypermail 2b30 : Tue Jan 21 2003 - 07:26:33 PST