On Wed, Sep 05, 2001 at 04:47:36PM -0700, richard offer wrote: > And we'd still have to move the in-kernel code into the module to capture > the error code as there are places that return different errno's depending > on the code path. [..] > vfs_permission() > sys_setpriority() > sys_setgroups() > sys_sethostname() > sys_setdomainname() Now, if I think I understand your needs, the four sys_set* functions here are being hooked for two reasons. The first is to provide some level of access control, the second is for the return values for an audit requirement. With these specific four, is the current hook insufficient for access control? I ask this primarily because system call interposition could be used to get the return value irrespective of the several different return values and short-circuit evaluations.. At least in these four cases. Of course, vfs_permission() isn't so easy to hand-waving fix. (As my tree doesn't even have a security_ops hook in vfs_permission, I'm not sure quite what the problem is -- the vfs_permission function only says that access is or is not granted, not what is done with that access once granted. So, I don't even see the audit potential..) I *do* like the specific examples, though. :) I think they do a good job of communicating what is wrong with the current approach, as much as SGI's needs are concerned.. _______________________________________________ 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 Sep 05 2001 - 17:35:34 PDT