Re: syscall convention

From: David Wheeler (dwheelerat_private)
Date: Wed Aug 22 2001 - 08:27:29 PDT

  • Next message: richard offer: "Re: syscall convention"

    Stephen Smalley wrote:
    >I again asked for an additional integer parameter in the sys_security
    >interface and syscall hook that could (optionally) be used by the module
    >for the purpose of module identification....
    >To my surprise, WireX seemed ok with the idea, and everyone else seemed
    >to want it.  But you weren't there, so feel free to chime in now.
    
    I _was_ at the BOF, and I can confirm that the attendees there _did_
    agree that that this was fine.  Greg, sorry you weren't there!
    
    It would be possible to make the "command" do double-duty
    (using it as both module-id and command id), as Greg suggests,
    but there are several disadvantages to using only 2 parameters:
    1. It's ugly.  Merging two parameters into one is usually undesirable
       unless the parameters are boolean flags (which these aren't).
       And this is a system call, so once added, its ugliness stays forever.
    2. It makes it MUCH harder for a dispatching module to cleanly dispatch things.
       When the parameter is separate, it can just look at the one parameter
       and dispatch, instead of ANDing (by what??) and looking.
    3. It makes the MD5 approach much more susceptible to collisions.
       Indeed, even if you don't use the MD5 approach, making the command do
       double-duty increases the odds of unintended collisions.
       An unintended collsion == code does "wrong thing", and it's worth
       including some protection against that since security modules
       (unlike the main kernel) can be moved in & out.
    4. It makes it much harder for static analysis tools, especially when
       analyzing programs (e.g., "ls") whose source code may be shared between
       several security projects.
    
    I don't see a change from 2 to 3 parameters as having any real performance
    impact. On the user side, it's setting a register or ORing a register, and
    on the kernel side, it's reading a register or reading-and-ANDing a
    register (for x86, but other platforms are similar).  There might be an
    imperceptible speedup (because packing & unpacking the parameters won't
    be necessary given 3 parameters).
    
    Clearly, some people want this to have 3 parameters, and I don't see
    a serious downside to having three parameters.  The usual rule on this list
    is that if one organization wants/needs something, and the others don't
    really care, then the organization that wants it wins.
    
    
    _______________________________________________
    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 Aug 22 2001 - 08:29:53 PDT