On Mon, 11 Jun 2001, Stephen Smalley wrote: > > 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. Security Through Obscurity aside (which I've been convinced is a silly concern), the idea of a macro for EVERY hook seems very workable to me. By creating "readonly-without-significant-effort" we achieve: 1) a reduction in vulnerability imposed by "poor" module programming outside the LSM. 2) access to the hooks by INTERESTED modules. 3) a uniform strategy for invoking hooks. I now agree that there's no substantial benefit of security through obscurity as protection against a wonton cracker. But I do see some benefit in encouraging as much as possible "polite" moderation by the registrar functions. Security exposures are not always "malicious", they are often accidental or incidental, and limiting these exposures increases the overall integrity of the system, in my view. I also like the "translation layer" suggestion made by Dr. Wagner. By reducing the interface to various access means logically instead of explicitly, there seems to be overall benefit. The cost is "optional" with the assertion that using the interface is "optional." Making it a "side feature" works very well for me, and centralizes the "decision making logic" as well as minimizes the "kernel delta" impact of LSM. I still believe that exposing the actual pointer to the security_ops structure should be an issue determined by the module. So a call to get_security_ops() could return the original pointer, a copy, a module side wrapper function, or even a failure, having been passed to "security_ops->get_security_ops()". The overhead is minimal, but the options opened up are many. If you couple "security_ops->put_security_ops()", as well, you have the possibility of complete read/write control at the module's discretion, I think, in a "polite" sense. As far as HOW the module determines access, there are already mechanisms in place that can be employed, I believe, and it is possible CERTAIN pointer replacements may be allowed by the module while others may not be. Or, in some cases, total exposure may be elected. Other module-side mechanisms may also arise. The concept of "caller specific modifications", while not supported yet, also raises it's head... especially if an "instance" value in the structure is returned. " A macro "lsm_call(instance-key,hook-index)" could arise in the future without substantial LSM MPI revision. (No need to aggressively deny the validity or need for this... just a random thought... not even sure I'd want to see it. :)) " Any chance we could grab an unused software interrupt somewhere to create an "lsmcall()" interface on the order of the "syscall()" interface? (Now going totally off page, so will sign off. (^_^) > > -- > Stephen D. Smalley, NAI Labs > ssmalleyat_private Still Thinkin' J. Melvin Jones |>------------------------------------------------------ || J. MELVIN JONES jmjonesat_private |>------------------------------------------------------ || Microcomputer Systems Consultant || Software Developer || Web Site Design, Hosting, and Administration || Network and Systems Administration |>------------------------------------------------------ || http://www.jmjones.com/ |>------------------------------------------------------ _______________________________________________ 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 - 09:30:42 PDT