On Fri, 5 Oct 2001, Seth Arnold wrote: > As a response to jmjones's recent question asking what is left, I felt > it might be useful to look at Stephen's todo list from a little while > back, and see just how much progress has been made since then. :) I also posted a list of things to do prior to submitting to the kernel developers on August 22nd. See http://marc.theaimsgroup.com/?l=linux-security-module&m=99849179205143&w=2. Other than the authoritative hooks patch, those items have all been addressed, except that I ran lmbench a little while back (rev 1.179), so we would naturally need to run it and other benchmarks against the latest version. > Well, our capabilities module still looks an awful lot like the > built-in capabilities support already in the kernel -- at least, it > doesn't do anything with the security blobs. Whether or not recoding to > support using the security blobs is a good idea or not, I just don't > know. Stephen, now that you have had a week's experience or so with the > second LSM-based release of SELinux, what do you think of the current > capabilities module? The last section of the overview document for LSM (in Documentation/DocBook/lsm.tmpl) discusses the current state of the capabilities module, why the LSM project has not yet moved the capability fields into the security blobs, and what additional changes to the base kernel would be necessary to move these fields. The current capabilities module is sufficient to provide the same functionality as the original built-in support with minimal overhead, and it allows for easy stacking with other security modules since it doesn't use the security fields. Hence, I'm satisfied with it. However, if the kernel developers decide that they want the capability fields moved into the security blobs, I'm ok with that as well. > I have no idea about progress on this front -- I don't know much about > the Linux networking code. I know I would appreciate it if someone could > assure me that the information available in the networking hooks allows > for dropping packets, mangling packets?, modifying the security state of > processes, based on rules including task information, interface, > addresses used, etc... I think that the current networking hooks are adequate for our needs. And I fully expect that they will undergo revision prior to being adopted into the mainstream kernel. > Hmm. We've got nfsservctl, quotactl, bdflush, swapon, swapoff, syslog, > and prctl covered. There isn't anything for the stime/settimeofday, not > that I could quickly see anyway. (There is a capable() hook in > do_sys_settimeofday, however...) Are there other miscellaneous > operations that still need hooks? :) We decided that settimeofday doesn't really need a separate hook - the existing capable call is sufficient for our needs. At present, I'm satisfied with the current set of hooks. > > 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. I made a pass to identify and fix these issues back at the beginning of August, and these fixes showed up in the 2001_08_07 patch. > Hmmm. There appear to be five uses of struct super_block and five uses > of struct vfsmount. I don't know enough about the individual hooks to > tell if this is fine, or indicitive of trouble. As long as you provide the vfsmount, we can always extract the super_block. But the vfsmount isn't always available at some of the hook locations. As a side note, I expect at least some of the kernel developers to favor hooks and security fields for vfsmount's and dentry's rather than super_block's and inode's (from the point of view that you should be able to tune security based on virtual namespaces). But from the perspective of nondiscretionary access controls, you want protection and labeling based on the actual object, not the name. Defining and assuring a security policy that is dependent on how objects are named is not pleasant. > Not on this list, but also important -- higher level documentation. The > SELinux team put together some decent enough high level docs; perhaps > they should be reviewed again with the light of trying to provide more > background/history/context for the project? (It might be the docs are > fine enough as they are. :) For revisions to the existing lsm.tmpl document, it seems appropriate to keep discussions and patches on this mailing list, since it is integrated into the BitKeeper tree. -- 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 : Mon Oct 08 2001 - 05:49:07 PDT