Sounds promising. richard offer wrote: >It doesn't get over the issue of performance (module faster than kernel). >But we can probably live with that. I didn't understand this remark. Should I try to understand what you meant by "the issue of performance", or is this a minor issue? Are you talking about optimizing the performance of calls that will be denied? Doing so seems to be pointless, as far as I can see. (See my last rant to the list for my argument why; I'm too lazy to repeat it. I'm not the only one to suggest this.) Are you talking about the possible existence of covert timing channels that can leak information? If so, I think we've discussed this on the list before and decided that this was not something we were going to worry about. Maybe you are talking about something else entirely? Forgive me if I am slow to catch the point. >It also means the placement is more critcal, we'd need to look over every >existing hook to ensure that it isn't being jumper over on an error. Yes, that's true. You mentioned that MAC-before-DAC is a key requirement in your group. Do you have the resources to do this look-over? Is this a major issue? _______________________________________________ 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 : Wed Jul 25 2001 - 22:34:28 PDT