aleph1at_private wrote: > The are as many as you can imagine: > > * Save in the CMOS non-volatile memory. > * Communicate via a serial port to a server. > * Save in a smart card. > * Save in a compact flash card. > * As parameters to LILO. > etc > > Some of them provide more capacity than others but no size fits all. Exactly. So LSM should not bind security modules to one solution, or even a preferred list of solutions. LSM modules should get their meta data from where ever they want. This may mean that an LSM-supporting kernel is not enough to support some modules (e.g. a fully compliant POSIX.1e module woudl require an inter-operable extended attributes file system to work with). The benefit of this approach is minimal kernel footprint for LSM itself (we don't have to include a funky persistent store) and broad applicability to many kinds of modules (we don't break security models that disagree with our preferred list of meta data stores). Crispin -- Crispin Cowan, Ph.D. Chief Scientist, WireX Communications, Inc. http://wirex.com Security Hardened Linux Distribution: http://immunix.org _______________________________________________ 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 : Mon Apr 16 2001 - 15:44:51 PDT