Thank you for the summary. I was unable to attend (this time) due to a last minute customer "emergency". :( I have a few "focussing" questions I'd like to pose in response, possibly for discussion... that I'd hoped to raise at the meeting. On Mon, 2 Jul 2001, Emily Ratliff wrote: > 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. Dummy-Modules-R-Us... more specific description needed, I'll put my people on one. > - 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. With regard to this, I assume "communicate an architecture" would encompass at least a "softly" explicit definition of a penultimate goal for the LSM services, against which future hook placements/decisions could be tested. The question of "IS" and "ISN'T" a relevant hook is an important one, and, to date, I'm not sure anything "softly explicit" other than "many need it" has been discussed. Define "many"? > - 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. I agree, even while I believe permissive hooks WILL be within the scope of "security decisions" eventually. My desire right now is to get a discussion/consensus about HOW... as far as naming, security_ops structure, and overall design philosophy before we "launch." I don't think the answer should be "duplicate everything we've done with an LSM-permissive project." Instead, I think "make allowances for future development" is the way to go. The advantages, in my mind, here, are clear: 1) developers working on restrictive only modules SHOULD have assurance that the hooks they're grabbing are restrictive only, 2) developers working on restrictive/permissive (authoritative) modules should not be encumbered by the interface, but have a clear path toward advancing it in a similar manner as the "restrictive-only" developers, including a logical place to target hooks in the interface, as an aside, I'm working on this, but expending a lot of cost/effort tracking the project at this point and hoping it'll "settle" for a while before it gets "fixed." 3) by creating, at least, "a temporarily idealized" model for evolving toward a more "complete" solution regarding security (please note: I view permissive security as also being "security") before we freeze this portion of the project, we can enjoy/inspire more "relevant" development in the Open Software paradigm. Solutions need not be complex, or invasive. They can be as simple as naming conventions, registration options, security_operations structure design. Not to show any disrespect to the pre-existant patch-security solutions at all, but to get into the "core-kernel", a "plan" that is workable not only NOW but into the next few Linux kernel releases is very desirable... otherwise, just patch-to-release and change the patches each time is where LSM may be positioned. > - The question of whether compatibilities should be a module came up but > was not really discussed. Compatibilities? Capabilities? or an attempt to address other Linux projects / other platform paradigms for security in our interface model? Forgive my inability to understand, please. > - 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. There is some value to knowing the original requested filename, but it's arguable (not by me, either way) that the actual entity is the inode. Protect THAT, you largely protect every link, every directory entry. INODE protection is crucial, i agree. There are other issues with userspace requested filenames... a few: 1) the way filenames are specified by the application may give clues to the means whereby the requesting application arrived at the the request. Theoretically speaking, any information has some value as far as security. If I *allow* access to /tmp/filename, I may not desire to allow access to /tmp/process/../filename. I'm sure there are a million better examples. 2) inode-only is insufficient to support restrictive/permissive models that allow only, for example, sub-directory limited type access... although interceptions of hard links, etcetera, CAN provide coarse functionality. It is envisionable that intercepting linking calls and then checking supplied filenames MIGHT be more efficient for certain modules, is it not? 3) there are many different ways to get to an inode. Protecting the inode is, therefore, desirable, but not "fine grained". I may be (, and am probably) wrong, but I would value a reference or off-line discussion that disproves the validity of these points. First things first, of course... the INODE specificity seems more important, but ANY data from userspace MAY be relevant. > - 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. Not ready. Close to workable. Unless, of course, the bitkeeper tree has evolved a LOT beyond the 2.4.5+lsm-2001_06_20 patch. :) Freezing things now (not hard freeze, but "first shot" freeze) may create too many invalid assumptions for Linus and the Kernel Developers. We're close, though... let's get to the "hard, first level" version before we "release." One VERY significant area which has not been "completely" discussed is socket/port access control, imho, and there are probably others. > - 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. I agree, on both counts. The documentation, so far, has been barely possible because the underlying concepts have changed radically as recently as June 20th, although, it is possible that it may be more stable now and some progress can be made. I invite anybody interested to send an email to majordomoat_private with the lines subscribe lsm-documentation end in the body. This is NOT intended to be an "exclusive" list to this one, but code->english conversions have their own "issues" and I would like to concentrate "likely interested" parties there. It's available to anybody who subscribes, and "results" will be posted here. As far as testing, I agree with the general statement, but don't think there's YET a clear enough architecture to design meaningful tests, beyond the generalized benchmarking. If there are specific technical issues that need be tested, I'd like to see discussions thereabout... and will gladly do what I can to help toward that end. majordomoat_private subscribe lsm-benchmarks end In essence, give me (us) a tighter definition of "meaningful" and we'll work toward providing it. > > 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. > Fingers crossed... customers and wives willing. > Please let me know about any misrepresentations, errors or ommissions. > > Emily > > Emily Ratliff > IBM, Linux Technology Center > Sincerely, J. Melvin Jones P.S. -- I'm STILL looking for the possibility of daily, weekly or biweekly bitkeeper-to-stable-kernel patches to help me keep "sync'd". I have bandwidth, I have storage... use me? Even if you have access to the bitkeeper tree and can do tar's, I'm interested. BitKeeper is KEWL, but not usable in EVERY situation. |>------------------------------------------------------ || J. MELVIN JONES jmjonesat_private |>------------------------------------------------------ || Microcomputer Systems Consultant || Software Developer || Web Site Design, Hosting, and Administration || Network and Systems Administration |>------------------------------------------------------ || http://www.jmjones.com/ |>------------------------------------------------------ _______________________________________________ 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 - 12:40:37 PDT