On Wed, 6 Jun 2001 Valdis.Kletnieksat_private wrote: > Don't forget all the *NON*-filesystem based permission checking as well. > > For instance, settimeofday() does checking, but never goes anywhere near > a filesystem that I'm aware of. And we *all* know that we want to be able > to create a security policy that allows NTP to diddle the clock, open port > 137, and nothing else... settimeofday uses capable(), which I had previously mentioned. When I said "just mean the call to inode->i_op->permission", I was still talking about what parts of the permission() logic would be moved into the module. Naively, the module would just duplicate the current permission() routine. But that still leaves filesystem-specific inode permission routines in the base kernel. My point was that the scope of "kernel logic" is poorly defined. I wasn't trying to be exhaustive. If you start to consider the full range of what might be considered security logic in the kernel, then you might reconsider wanting to move it all. -- Stephen D. Smalley, NAI Labs ssmalleyat_private _______________________________________________ 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 Jun 06 2001 - 10:57:58 PDT