On Don, 19 Apr 2001 Crispin Cowan wrote: > In particular, the validity of kernel modules is a very fine thing to work on. The > catch is that validity is a cascading sequence of trust that goes all the way back to > the reset pin on the CPU (and right inside the CPU, if you are that paranoid). It's > like this: > > * the CPU needs to validate a signature on the BIOS, to make sure it has not been > flashed by an attacker > * the BIOS needs to validate lilo (or whatever boot sector thingie) to make sure it > has not been corrupted > * lilo needs to validate the kernel, to make sure that /boot/vmlinuz has not been > corrupted > > Only then does it add value for the kernel to validate the LSM module, because only > then can you trust that the kernel itself has not been corrupted. root can corrupt any > of these stages, so if we only harden the LSM interface, it just squishes the problem > elsewhere. I disagree slightly: You can avoid changes to BIOS, LiLO and kernel via access control, as long as the system is running. All you need to prevent are physical access to the Hardware and to the BIOS settings and that another system is booted, e.g. by providing controlled kernels only and no boot from other devices. Let's concentrate on interfaces etc. now. As far as it looks, all the hook stuff will be usable from fixed code as well. And the only thing missing for my goals is early automatic module loading, what could be easily achived via a module pre-loading functionality after init fork and before running init program, e.g. with kernel parameters. My concern is to get control as early as possible and then keep it until system is switched off. Amon. PS: Sorry, I won't work through the bootstrap on all supported archs. _______________________________________________ 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 : Fri Apr 20 2001 - 01:58:54 PDT