LA Walsh wrote: >In the same way you don't want to return >a DAC failure when the user doesn't have "access" to the data in the >inode needed to perform a DAC check, instead they should get a MAC failure. I'm sorry, you lost me there. On Linux, a failure is a failure is a failure (it's all 'return -EPERM;'). What am I missing? >Given that audit requires more hooks than are currently present [...] Audit is a separate issue, and it seems one might need fairly different mechanisms to support it. Actually, I believe this has been discussed in depth on this list before, and from my recollection, I don't remember hearing any explanation why simple syscall interposition won't suffice for this purpose. It's not clear to me why one would expect that the right place to do audit is deep in the guts of the kernel; can you help me to understand? >2) move to authoritative hooks with the standard security moved >into a module that is compiled in and [...] This has also been discussed at length on the list. My understanding is that most people felt that this would be too drastic a change---it would put acceptance of LSM into the mainline kernel at risk. Can you give any more specific arguments why we authoritative hooks are critical? Concrete examples would be helpful. _______________________________________________ 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 : Sun Jul 08 2001 - 23:04:17 PDT