Quoting Valdis.Kletnieksat_private <Valdis.Kletnieksat_private> on Thu, Jul 24 16:23: > > There's also a rather nasty race condition in the time between when the binary > itself gets started by exec(), and the runtime loader resolves all the shared > libraries and you actually get to main()..... As each library gets loaded off the disk it will get checksummed, independently of the binary. I think I understand. /bin/ls gets executed. My module sits in the file_permission path, verifies the binary on disk is correct and allows the load to continue. Between the time I make my decision and the time the pages actually get loaded off of disk, someone manages to sneak a Trojan'd binary in. The execute actually happens and the Trojan'd binary loaded. One side effect of my module is that it uses kernel_read to read the contents off disk and SHA1 them. The pages will then be cached for the actual execute. I do not see a race there. If the kernel detects a page has changed and needs to reload it off disk, then I need to catch that and recheck the contents of the file. How do I make sure that I catch every valid (not direct to /dev/hda1, memory, or swap) write and clear my cached bit? I do not believe the direct access can be protected against from this module. But this module could stack with something (SELinux?) that provides those protections. -- "Sure, I am generalizing from a single example, but everyone does that - I know I do."
This archive was generated by hypermail 2b30 : Fri Jul 25 2003 - 12:57:38 PDT