Hi, For those of you who could not make the Kernel Security Extensions BOF at USENIX last week, here are a few notes and comments. Those of you who did attend please weigh in with your corrections and additions. The BOF started off with Robert Wilson talking about his TrustedBSD project. Amon Ott spoke about RSBAC. Peter Loscocco spoke about SELinux and Crispin Cowen spoke about the LSM project. (Interesting sidenote: Crispin said that there are now 470 addresses subscribed to the LSM mailing list.) Each talk was fairly short. When the talks were completed, the floor was opened to questions and comments about the LSM project. Peter Loscocco spoke about what happened at the Kernel Summit in March to get the project started. The primary issues discussed included - one person (I didn't catch his name) expressed a strong need for a dummy module that exercises each hook to use in regression testing each new kernel. About half the audience seemed to agree, with the other half saying that the hooks that were interesting for active security modules would thrive and be tested against each new kernel version by default and that it would be ok if the other hooks died out. - Peter Loscocco expressed that it is important that the LSM project be able to communicate an architecture for the hooks to be accepted by the kernel developers. There was no further discussion of this point. - The question of allowing permissive as well as restrictive hooks was discussed. The general consensus was that it would be best to allow restrictive hooks only at this point. The goal is to get the basic hooks into the kernel and expand into permissive hooks if they are deemed necessary and prudent at some later date. - The question of whether compatibilities should be a module came up but was not really discussed. - Stephen Smalley brought up the issue of duplication of some of the hooks. For instance, some code paths call two separate LSM hooks. One example of this is the hook at attach_pathlabel and at the inode level. Stephen felt that this would be frowned on by the kernel developers. One member of the audience (didn't catch his name) felt that the LSM project should argue that this duplication was inevitable and that rather than calling it a "duplication" which has negative connotations, it should be called an "overlapping" of functionality. Douglas Kilpatrick who does the wrappers project for NAI said that they use pathnames for convenience but he feels that making security decisions at the inode level is the correct thing to do. Stephen Smalley is ok with that as SELinux makes decisions at the inode level, but other project like SubDomain and LOMAC make security decisions based on the pathname. Someone said that eliminating the duplication of these hooks would impose limitations on the policies which could be LSM modules which is clearly not what LSM wants to do. The discussion was tabled with no decision made. - Crispin Cowan said that the LSM project is near snapshot level ready to be sent to Linus when development on the 2.5 kernel is opened. There was only lukewarm support for this. Many people seemed to feel that some of the other issues should be worked out first. - Stephen Smalley brought up the issue that the LSM patch hasn't had sufficient testing or documentation to know what locks are held when the hooks are called and what locks should and should not be acquired in the hook code. The LSM patch hasn't been sufficiently tested on SMP machines. More performance testing also needs to be done at both the macro and micro test level. Finally it was agreed that there would be a LSM specific BOF at the USENIX Security conference in Washington DC in August. Timothy Fraser of NAI Labs is setting up that BOF as well. Please let me know about any misrepresentations, errors or ommissions. Emily Emily Ratliff IBM, Linux Technology Center _______________________________________________ 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 Jul 02 2001 - 10:18:45 PDT