Hi, The discussion of bprm_apply_creds reminded me of another issue with respect to stacking: the holding of task_lock(current) across the bprm_apply_creds() call. Currently, SELinux invokes the secondary_ops hook first and then performs its own checking and task security structure update, and then releases the task lock prior to performing the rest of its processing, as we do not need the task lock for the rest of the processing and holding for that processing would introduce additional nesting of locks that is undesirable. Then, prior to returning, SELinux re-takes the task lock so that everything works smoothly when compute_creds tries to release it. This becomes a problem if you want to stack another module with SELinux via stacker that also performs processing in bprm_apply_creds() and relies on the unsafe flags, as they may no longer be accurate due to the temporary dropping of the task lock by SELinux. You essentially have to make SELinux the last module in the stacker chain to make that safe. But that is difficult given that SELinux must be built-in, unless there is an explicit way for SELinux to ask to be placed last (e.g. a priority for registration) or stacker knows that SELinux should always go last. The other option would be to split the bprm_apply_creds hook into two separate hooks, and only hold the task lock across the first hook call, moving the SELinux processing that doesn't require the task lock into the second hook function. The first hook would need to pass back some state to the caller to propagate to the second hook. In the case of SELinux, we would need to pass the information needed to perform the avc_audit() calls for the share and ptrace checks. That would certainly be cleaner, but again introduces a situation where we are making two separate hook calls at the same call site. -- Stephen Smalley <sds@private> National Security Agency
This archive was generated by hypermail 2.1.3 : Thu Dec 09 2004 - 06:51:56 PST