Re: backward compat / access (was Re: Benchmarks)

From: Luc Pardon (lucpat_private)
Date: Wed Apr 18 2001 - 00:53:22 PDT

  • Next message: buddy: "Re: backward compat / access (was Re: Benchmarks)"

    Hi,
    
      Some thoughts from a humble programmer.
    
    > We're not trying to add "will I be able to do 
    > this" syscalls ! 
    > Not that it wouldn't be usefull (though I don't have
    > any example in mind right now), 
    
        An application developer may want to inform the user that (s)he
    doesn't have sufficient rights to do something, without actually attempt
    to do that "something" and set off all kinds of alarms. Sysadmins hate
    false alarms (rightly so), and tend to extend that feeling to the users
    that provoke them. Compare it to the "this program must be run as root"
    message that many utitities issue.
    
      This is assuming that security violations would be logged, or at least
    there is a facility to do this logging, e.g.:
    
      if (is_xyz_allowed(&xyz_info) == OVER_MY_DEAD_BODY)
      {
          log_invalid_xyz_attempt(&xyz_info);
          return BAD_BAD_BAD;
      }
      // else it was a YES_GO_AHEAD
      // .. business as usual
          
      It would require two sets of hooks, but the second hook would be
    called only in the "bad" case, so performance is less of a concern here,
    IMVHO. The syscall will fail anyway <g>.
    
      It is up to the LKM to decide if/what gets logged, but the kernel
    could provide the facility. It's just like firewalling, that would be
    much less useful without logging.
    
    > but it's IMHO a task 
    > that is out of the scope of this project.
    
      Maybe not if you provide a set of wrapper functions that fill out the
    structure and then call the hook function, e.g.:
    
      Boolean would_xyz_be_allowed_if_I_wanted( /* mimimal set of parameters
    */
      {
          struct xyz_info = ...
          // set up xyz_info just like the real thing
          return is_yxz_allowed(&xyz_info);
      } 
    
      The "minimal set of parameters" would essentially be the same as those
    of the normal system call. In fact, this same "wrapper" function could
    be the one used by the actual syscall, maybe ? If so, no code bloat,
    just expose a few more functions.
    
      As an aside, I would have the kernel populate the function pointer
    tables with default "immediate return" functions of its own, and replace
    them with LKM functions when the KM gets L'ded.
    
      Benefits:
    
      * no need to worry about null pointers
      * LKM developer need only provide the needed functions, not a zillion
    empty ones
      * some backward compatibility as long as Kernel X+1 only _adds_ hooks
    and leaves the structs of Kernel X intact.
    
    
      Just my 0.02 Euro's,
    
      Luc Pardon
      Skopos Consulting
      Belgium
    
    _______________________________________________
    linux-security-module mailing list
    linux-security-moduleat_private
    http://mail.wirex.com/mailman/listinfo/linux-security-module
    



    This archive was generated by hypermail 2b30 : Wed Apr 18 2001 - 00:55:58 PDT