* Greg KH (gregat_private) wrote: > On Thu, Jun 07, 2001 at 04:41:40PM -0700, Chris Wright wrote: > > fs/binfmt_elf.c > > > > if (!bprm->sh_bang) { > > retval = security_ops->file_ops->permission (bprm->file, MAY_EXEC); > > Doh, wasn't thinking about the current modules. There are lots of other > places that will also need access (see all of the current capable() > checks in drivers that can be compiled as a module.) 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? I feel the obscurity security value of not exporting the struct to modules so they can't mess with it is outweighed by the value added when (non-lsm) modules can use the entire security_ops struct for fine grained access control. > I agree, it will need to be exported. Assuming no one else has major objections, consider the security_ops struct exported. -chris _______________________________________________ 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 Jun 07 2001 - 17:36:24 PDT