> Titus, I'd like to hold off on this patch as it stands. Often our hook > placement is after the DAC logic precisely so that the security module > knows that the DAC logic has already been satisfied, that way it doesn't > need to repeat those checks. Casey and crew from SGI are putting together > a proposal for auditing hooks. I'd like to see how their hooks may > satifisfy your needs. If not, we can look at other alternatives (like > Wagner proposed). I understand the logic behind it, and from a general standpoint I can't argue with you at all. Takes a bit of tweaking to get the hook logic safely in front of the DAC logic, and is probably unnecessary in most cases. Still, it's the only way that we can get done what we need. I'm fairly reserved to the fact that it isn't going to be accepted this way (I was actually fairly surprised when initially it was said that supporting honeypots would be something we should shoot for), but I must admit that I'm a bit dissapointed. Auditing checks isn't enough, we need to make sure that the existence of some files is not betrayed, and that requires things to be done in this slightly backwards fashion. I'll hang around and lurk for a while, to see if things move to a paradigm that can support this (which I'll certainly voice my support for) but otherwise I guess I'm going to have to do the nasty and just be using a kernel patch. -Titus _______________________________________________ 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 Jun 22 2001 - 09:02:39 PDT