* Matt Block (mattat_private) wrote: > > "I'd love to help, but I'm not much use at anything but a supervisory > position. > You boys just keep working on that fence, and I'll sit back over here > and > critique. You know, only the BEST white-washers get to paint that > fence." > > Is there a clear list of projects on which help is needed? I may be misunderstanding you, but... * all current lsm hooks need to be audited for proper placment and enforcement * all combinations of alloc/free should be closely examined for memory leaks. i just found a leak in the binprm alloc/free placement thank's to the work that jmjones is doing with lsmexample.c. * any hooks that are in the interface that have no kernel placement should be placed (or thrown away if they aren't useful). * we are working on a good story for networking. * the current hooks are inconsistent in their placement relative to the DAC checks (some before, some after). this should be unified. we had been moving them to be after the DAC checks (but as richard offer pointed out posix MAC checks should come before DAC checks) hmmm...quandry * i'd like to scrutinize the mount hooks and try to form them to the kernel super block object in a way that is consistent with other hooks (i.e. clever ways to put them in the super_block_ops struct). * identify kernel objects that we are not yet protecting. * what to do with the inode/absoute pathname issue? -chris _______________________________________________ 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 Jul 13 2001 - 16:56:25 PDT