* jmjonesat_private (jmjonesat_private) wrote: > > Please note that I do NOT believe EVERYTHING possible needs to be > addressed explicitly in the LSM interface. I *do* believe that everything > *noted here* needs to be evaluated fairly deeply before we abandon support > in favor of the the "smallest/least intrusive" method. If there's a > mechanism already existing "below the surface" to implement, then > rejection is appropriate. if you can show me that the authoritative patch fundamentally provides features that you can not produce currently than i'm convinced. if in your module you use the capable hook as an in-kernel override mechanism (return 0 from your module's capable implementation), then you will always trigger the restrictive lsm hook. i have not done a full look at the hooks, but can you cite specific kernel code where this won't work? (the obvious would be in-kernel check that is not coupled with a call to capable). if you care about the result from the in-kernel check it is really boolean, the kernel code doesn't conditionally set the error return code based on what part of in-kernel check failed[1]. so if you call into module via capable you know you failed the in-kernel logic, otherwise you passed it...audit accordingly. -chris p.s. here are some interesting statistics based on the current ChangeSet (1.185) versus the 2.4.9 vanilla kernel. the authoritative one is basicall Stephen's recent repost of his authoritative patch ported forward to 1.185: autoritative patch size (bytes) lines removed lines added NO 187974 313 2944 YES 194120 357 3000 _______________________________________________ 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 : Tue Sep 04 2001 - 15:52:47 PDT