Chris Wright wrote: >Yes, this is exactly what I was getting at. However, I found that drivers >tend to call only capable() and permission() and the binfmt modules call >compute_creds(). And, all these cases are already handled by exporting >these functions as wrapper functions to the corresponding security_ops >functions (making sure they are not just static inline functions). So >my question is, do we think this is sufficient granularity for modules >(non-lsm modules), or should they get complete access to the security_ops >struct? Here's one reason *not* to export security_ops. I think there's value to forcing modules who want to install hooks to do so through a central registration interface. Today, one small benefit is that the registrar can add the hook in a sane way. I've noticed empirically that many modules which hook into the Linux syscall interface do so in a blatantly bogus way: They are not race-free, they can fail badly in the presence of other modules that also hook into the same interface, and so on. The registrar can easily ensure that hooks are added to security_ops in a reasonable way, acquiring the necessary locks, enforcing the 'at most one module' requirement, and so on. In the future, I expect that there may be much greater benefits. In particular, if/when we tackle module composition, I believe we will find that the composition problem will be much harder to solve if LSM's were allowed to add themselves into security_ops without supervision; I fully expect that focing all LSM's to go through a registrar will make our lives much easier if we undertake to add some support for composition. By the way, I see no merit in `security through obscurity' arguments (and I'm sure you'll be glad to hear that I'll say no more). 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. _______________________________________________ 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 : Fri Jun 08 2001 - 18:15:32 PDT