On 9 Jun 2001, David Wagner wrote: > Therefore, I'd argue for not exporting security_ops in a form that > allows write access. Read-only access would be fine, if there were a > way to enforce the read-only restriction; at present, exporting wrappers > around capable(), permission(), and compute_creds() as necessary may be > the easiest way to achieve this. Not exporting security_ops and defining wrapper functions would not truly prevent direct modification of the security_ops structure by a clever module, but it would certainly discourage it. Defining wrapper functions for the few hooks needed by existing modules would not be hard, but it seems desirable to allow future modules to invoke many of the security hooks for performing fine-grained permission checking (or other security functionality). Are there any LSM hooks that we would not want to allow direct invocation by modules? If not, then it seems we would need to define a wrapper function for each hook. If we follow this route, then we would presumably always call a macro that would be defined to directly dereference the security_ops structure or to call the wrapper function depending on the context in which it was called. -- 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 : Mon Jun 11 2001 - 07:10:27 PDT