On Thu, 11 Jul 2002, Stephen Smalley wrote: > > On Thu, 11 Jul 2002, James Morris wrote: > > > No, I was waiting to see if there would be any further feedback. > > I don't have a strong opinion on the issue. We certainly don't need the > LSM IP glue as part of the base LSM framework, but it is already a > separate configuration option, so it doesn't impose any cost on modules > that don't use it. > Although, it does impose unnecessary cost on modules which do use it if they don't use all of the hooks. Modules using lsm_ip_glue are also limited to the default hook priorities and hook placements. Of course, they can override these by using Netfilter directly, which somewhat defeats the purpose of the glue module. The existence of the IP hooks, glue code, configuration options etc. unnecessarily increases the complexity of LSM, which is bad in terms of security practices and kernel bloat. I agree with Chris that the hooks are nice to have as part of the LSM API, but I don't think that's enough justification for keeping them. From a module development point of view, removing the IP hooks would mean composition of the Netfilter API with LSM. I don't feel that this is a problem, as the glue code is merely a thin layer on top of Netfilter, and users of the IP hooks need to understand the underlying mechanisms anyway. Improving flexibility, improving performance (for some cases) and reducing complexity/bloat are good reasons for removing the hooks, I feel. There is also the issue of how a kernels are likely to be distributed by vendors. Would a vendor be likely to release a kernel with the IP hooks disabled, or even as a module? Consider that the module is not dependent on anything, and could lead to a security hole if it it was needed but not loaded. So, even as a configurable option, vendors will have to decide what to do: static build imposes overhead and modular build unnecessarily complicates deployment. The IP hooks have been good during LSM development, but as we move to gain kernel acceptence, this is something I think we can now discard as not strictly required and less than optimal for many scenarios. - James -- James Morris <jmorrisat_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 : Thu Jul 11 2002 - 07:10:24 PDT