Golly, Seth, you get an A+ on this response, it's chock full of analysis. Well done. 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. :) > > On Thu, Aug 02, 2001 at 12:05:02PM -0400, Stephen Smalley wrote: > > 1) Move all hook calls after the DAC logic. > > Hmm. This appears to have been mostly done, as long as we allow some > fudging on the definition of 'DAC'. :) I think this has been done in every case where it is consistant with the original intent. Since Mr. Smalley positted it, can he "sign off"? > > > 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. > > 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? Hrm. I think the capabilities module that LSM currently has does emulate the original code fairly exactly. I think this answers the importance of having it. As far as "more" ... in essence, actual extension of security to the kernel... I thought the argument was that specific changes for restriction only would be useful, and any changes that accidentally/coincedentally supported anything else are okay, but any changes for OTHER reasons would be discouraged/rejected. Security blob support, for a mostly permissive interface, should be considered extremely carefully, imho. > > 3) Continue to define and implement > > additional networking hooks based on our experiences > > with using the current networking hooks for our various modules. > > 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 agree. Can the authors/commiters of that functionality write a few lines on that topic? > > > 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). > > 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? :) Agreed, within the specified "restrictive" sense. > > > 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. > > Good idea. > Good idea, but I suspect that, except for the userspace pointer issue, this is not "provable" but, rather, demonstrable. I think we're mostly there as far as LSM-local solutions are concerned... if there are any others, let's hope the KD's point them out. > Are there any hooks that people would like to nominate for removal? :) ? What is the critera for removal? > > > d) See if we can make the file system hooks consistent in their > > usage of struct vfsmount vs. struct super_block. > > 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. Who knows? Anybody? > > 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. :) The comments added to security.h seem to be consistant with the documentation needs of a presentation, imho. More documentation is both necessary and desirable, imho, from comments to a "HowTo" to a "Dummies Guide" (no violation of any copyright/trademark inteneded), but I don't necessarily think them advisable or necessary *NOW*. After all, whatever is bundled in a dummies guide will get the scrutiny of Linus and the KD's, as well as LSM, before acceptance. "Spin" may matter in the sale. I expect to present after-acceptance documentation, but not until the "politics/spin" is determined. AFTER the sale, spin is important, too, but it can be "fixed" by LSM. As a testimonial, the current documentation is more than adequate for me to evaluate and decide if the current hooks are desirable/useful for my application. If any further clarification for anybody on this list is necessary, speak now, please. :) > Comments? > See Above, J. Melvin Jones Proposed: LSM is ready to start the "sale". Are there any voices against that position, and WHY? |>------------------------------------------------------ || 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 : Fri Oct 05 2001 - 16:06:51 PDT