Re: syscall convention

From: Crispin Cowan (crispinat_private)
Date: Tue Aug 21 2001 - 15:48:40 PDT

  • Next message: David Wagner: "Re: syscall convention"

    David Wheeler wrote:
    
    > Several people have suggested having the "security" system call
    > with an additional argument that indicates WHICH security module is the
    > intended one (basically a magic number).  I think this would be wise, but
    > one common comlaint is "who manages the magic numbers?
    >
    > Rather than create an IANA for magic numbers, why not just have a convention
    > where the magic number is the first 32 bits of the MD5 hash of the name?
    > Then the magic number for "selinux" is "0xf97cff8c", as determined by:
    >   echo -n 'selinux' | md5sum | head --bytes=8; echo
    
    Theorem due to Andy Tanenbaum: randomly chosen 64-bit values are unique :-)
    Tanenbaum used this to enforce capabilities in the Amoeba distributed OS.
    
    At the DC LSM BOF, the group consensus was that there would be no IANA for
    module numbers, but we would add one additional int (or unsigned, I forget)
    argument to the LSM syscall.  Individual "vendors" (loosely defined) that want
    to multiplex multiple modules (e.g. Immunix; SubDomain, RaceGuard, CryptoMark)
    can use the argument to do so, and arbitrary consortia of projects (e.g.
    SELinux and SGI) can make up ad hoc methods of partitioning the space of ints
    so as to assign unique IDs to individual modules.
    
    David's suggestion for a method to assign module IDs is a good one, and
    consortia who want to cooperate should consider using it.  An alternative
    suggestion is to assign each vendor a range of numbers, similar to the way that
    Ethernet MAC addresses are managed.
    
    But we probably shouldn't enforce such a convention in code: too many people
    feel too strongly that the whole IANA thing is broken, so the extra argument is
    just provided for people who want it for "something", possibly including module
    IDs.
    
    Crispin
    
    
    >
    >
    > Here are a few magic numbers:
    > janus     df256845
    > subdomain cd9fb496
    > selinux   f97cff8c
    > sgi-capp  b759117c
    >
    > This approach has the following advantages:
    > * It's simple.
    > * It does _NOT_ require a central registration system.
    > * It helps apps make sure that they talking to the "correct" module.
    >   Otherwise, there's the danger of a program executing the system call to
    >   cause one action, but another is caused instead.  This is particularly
    >   a problem with ls, etc.  I think this is very analogous to the
    >   reboot(2) call, which uses magic numbers to protect against
    >   programs gone unintentionally awry.
    > * It makes stacking quite sensible -- the stacking module simply needs to
    >   know the magic numbers of each module (which it can get from the module,
    >   or even simply compute from the name if EVERY module being stacked
    >   obeyed the convention).  Then, when the security system call is
    >   requested, the stacking module can forward the system call to the
    >   right module.
    >
    > _______________________________________________
    > linux-security-module mailing list
    > linux-security-moduleat_private
    > http://mail.wirex.com/mailman/listinfo/linux-security-module
    
    --
    Crispin Cowan, Ph.D.
    Chief Scientist, WireX Communications, Inc. http://wirex.com
    Security Hardened Linux Distribution:       http://immunix.org
    Available for purchase: http://wirex.com/Products/Immunix/purchase.html
    
    
    
    
    _______________________________________________
    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 : Tue Aug 21 2001 - 15:50:54 PDT