We seem to be rehashing old issues without any real justification, and this is impeding forward progress on LSM. Authoritative hooks were discussed, implemented, and discarded back in June. Moving DAC out of the base kernel was discussed and rejected. The ordering of the hooks with respect to DAC has been debated endlessly, but the arguments for putting the hooks first seem to have been effectively countered on this list. And the "demise of simple assurance" is nothing new, definitely not a surprise to me, and presumably not a surprise to anyone who is actually implementing a LSM module. Of course modules can modify the structures (and in some cases, this is quite desirable and necessary for implementing the desired security functionality). Even without the explicitly passed structures, many modules will be inspecting the state of the current task (and in some cases changing it). I propose that we stay with our previous decisions on these issues, and make forward progress on LSM, e.g.: 1) Move all hook calls after the DAC logic. 2) Complete the capability module, as this is an important selling point for LSM. This means moving the capability-specific logic from access, capget, and capset into the module, possibly moving the capability bits from linux_binprm and task_struct (and perhaps some of the network-related structures) into the security blobs, and fixing any remaining kernel references to the capability bits. 3) Continue to define and implement additional networking hooks based on our experiences with using the current networking hooks for our various modules. 4) Consider hooks for miscellaneous operations like nfsservctl, quotactl, bdflush, swapon, swapoff, stime/settimeofday, syslog, prctl (some of these had hooks defined in the SGI patch). 5) As previously recommended by Chris Wright: a) Review all current hook calls for placement, error handling, and parameters. With respect to parameters, be sure that we aren't passing user space pointers or at least explicitly mark such parameters. b) Review the alloc/free hook calls for leaks. c) Place or remove any unused hooks. d) See if we can make the file system hooks consistent in their usage of struct vfsmount vs. struct super_block. -- Stephen D. Smalley, NAI Labs ssmalleyat_private _______________________________________________ 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 : Thu Aug 02 2001 - 09:08:53 PDT