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