On Fri, 7 Sep 2001, Lachlan McIlroy wrote: > I'll keep looking... You don't need to keep looking. Chris Wright already pointed out a better example - the use of CAP_SYS_ADMIN in sys_umount to override the DAC restriction on unmounting a file system owned by someone else. That is a clear case where you cannot arbitrarily grant the capability, since there are many cases of CAP_SYS_ADMIN without a subsequent restrictive hook. So the argument that capable+restrictive is just as expressive as authoritative has been effectively countered. 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? So, now perhaps you/SGI could respond to Greg's complaints about the patch (http://mail.wirex.com/pipermail/linux-security-module/2001-September/001871.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/001872.html), but I don't think you or SGI have said anything. 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. -- 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 : Fri Sep 07 2001 - 05:31:29 PDT