* frm sdsat_private "09/07/01 08:30:11 -0400" | sed '1,$s/^/* /' * * * And I think that Richard has spoken for SGI in saying that basic * authoritative hooks are sufficient for SGI, even without addressing the * early short-circuit problem. But could someone clarify who speaks * authoritatively for SGI, since Casey seems to have contradicted Richard at * points, and I'm not really clear how you (Lachlan) relate to the SGI team? My interpretation of Casey's comments (he's out today, and at CHATS next week, so perhaps someone there can ask Casey to publically confirm this, in case he doesn't see this) is that Casey was saying that if go in with capable()+restrictive approach to provide semi-authoritaitve hook-like features that human optimisaion will likely lead to the the restrictive hook being bypassed. The issue isn't one of code, more of philosophy and self-documentation, restrictive hooks can (and will) be bypassed if someone thinks they already know the answer. Going in with a strongly worded "the default behaviour of hooks is authoritative" at least reduces the risk of over-zealous human optimization. Even if in some cases an individual hook may be positioned in a non-authoritiative manor, the "majority rules" in terms of hook behaviour. I think my earlier response says it best " The proposal known as "semi-authoritaive" hooks is useful to SGI. Its not perfect, but we can live with the deficienies. We realize that any wide-spread hook re-positioning to absolutely avoid all-short circuits isn't going to get accepted either by LSM or the kernel developers, but that's not to say there wont be minor bug-fixes that we will propose as and when we get hit by them. We will try to work around any issues we hit and only suggest a bug-fix as a last resort. " We can't definetively say that the current proposal is 100% perfect until we have passed an evaluation (which is way past the lifetime of LSM), so I have left room to move, but the intention is to try and work around any if at all possible. Hopefully that has cleared any confusion, the intended goal is the same ( (semi) authoritative hooks), not capable()+restrictive) we're just arguing for them from different directions. * * So, now perhaps you/SGI could respond to Greg's complaints about the patch * (http://mail.wirex.com/pipermail/linux-security-module/2001-September/001 * 871.html), specifically the repositioning of some of the capable calls * and the reordering of the ptrace logic. I provided my $0.02 on those * issues * (http://mail.wirex.com/pipermail/linux-security-module/2001-September/001 * 872.html), but I don't think you or SGI have said anything. We can do this, we'll try to get a ptrace only patch for discussion asap, hopefully Monday. * And perhaps * you could take a hard look at the authoritative hooks patch and give a * better sense as to whether all of it is really necessary or even * desirable from your perspective. If there are parts of it that you * wouldn't even use, then we shouldn't even consider them. We will look, but as we'd like everything to be authoritiative (within the bands of pragmatism), I doubt there will be much that we wont want to make use of. In particular, my concern is that the more the division of authoritative/restrictive hooks moves away from authoritative, the harder it is going to be to maintain the concept of "semi-authoritiative" and it will increase the likelyhood of subsequent kernel developers bypassing hooks (un)intentionally. For all reasonable intents, Lachlan is a full technical member of the SGI Trust Technology team (whether he likes it or not :-) he just gets to eat more Timtams than us poor US-based members :-( * * -- * Stephen D. Smalley, NAI Labs * ssmalleyat_private * richard. ----------------------------------------------------------------------- Richard Offer Technical Lead, Trust Technology, SGI "Specialization is for insects" _______________________________________________________________________ _______________________________________________ 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 Sep 07 2001 - 10:51:44 PDT