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

lucpat_private

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