On Wed, 25 Apr 2001, Chris Wright wrote: > yes, i had the same needs and made ptrace take two task_struct pointers. Was this change supposed to go into the latest patch? It doesn't appear to be there. > > fs/exec.c (compute_creds): We need a hook on the bprm to check sharing > > of state across an execve (similar to the existing checking > > performed for sharing state across a set[ug]id/capability > > enhancement exec), change the attributes of the process, > > and wakeup any sleeping waiters if the attributes changed > > so that the wait4 permissions can be rechecked. > > i added this. compute_creds is now part of the lsm interface. Rather than changing all calls to compute_creds to call the LSM hook, I would suggest leaving a minimal compute_creds function that handles the setuid/setgid processing and calls the LSM hook for all other work. Otherwise, how will the system work with a null security module? By the way, I think that the latest patch is broken for this reason - I get a kernel NULL pointer dereference during initialization in load_elf_binary, regardless of whether the capabilities plug is statically linked or dynamically inserted. > i've been working on moving all capable() calls to the lsm interface rather > than moving lsm hooks into capable(). What if you took an incremental approach - add a hook now to capable so that you have immediate coverage of all existing capable calls, and then incrementally insert your own finer-grained hooks into the same locations as the current capable calls (in order of priority, starting with highly privileged operations whose capabilities are too coarse grained), and then ultimately remove the hook from capable when/if you address all of the individual capable calls. Personally, I don't think you'll ever reach that last stage - the amount of work doesn't seem justified by the value added. I would expect you to stop with a mixture of hooks for operations where we want finer-grained control plus the wide ranging coverage provided by the existing capable calls. -- Stephen D. Smalley, NAI Labs ssmalleyat_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 Apr 26 2001 - 07:56:06 PDT