Casey Schaufler wrote: > Crispin Cowan wrote: > > So, are there other reasons to put MAC first? Can someone who wants MAC first > > wheel them out, so that we can attempt to compare the Bitch mode issue against > > these reasons? > On a system with MAC and audit (e.g. B1) you want the > audit record to include the fact that MAC access was > denied over the fact that DAC access was denied, as MAC > violation is more likely to be a serious breach. > > I certainly see the value for MAC after DAC on your system. > The best way to address this conflict would be to have > DAC included in the security module. If that's not going > to happen, someone is going to have an unhappy implementation > using LSM. I don't see how the above follows. The MAC hooks are almost all restrictive. So if the MAC check goes first, and the module denies access, you have no way of knowing whether or not DAC would have granted or denied access. Conversely, if the DAC check goes first, you have no way of knowing whether the MAC check would have granted or denied. So how could EITHER sequence support full audit denoting which component denied the access? Are you really losing valuable audit information if an access is deined because of DAC, whne it also would have been denied because of MAC? BTW, the LSM hooks are not necessarily MAC hooks. It is just the common case that LSM modules are often MAC modules, but I can imagine some kind of wizzy enhanced DAC module built for LSM. Crispin -- Crispin Cowan, Ph.D. Chief Scientist, WireX Communications, Inc. http://wirex.com Security Hardened Linux Distribution: http://immunix.org Available for purchase: http://wirex.com/Products/Immunix/purchase.html _______________________________________________ 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 : Mon Jul 23 2001 - 22:41:22 PDT