On Wed, Oct 20, 2004 at 08:23:31AM -0400, Stephen Smalley wrote: > On Tue, 2004-10-19 at 17:09, Chris Wright wrote: > > * James Morris (jmorris@private) wrote: > > > Yes, it's the runqueue lock. One simple possibility would be to convert > > > the audit code over to use the keventd workqueue, and use > > > schedule_delayed_work() to kick the audit logging via a timer in this > > > case. > > > > Yeah, guess that would work, but it's not that nice a solution ;-/ > > And requiring security modules to special case CAP_SYS_NICE auditing in > their capable() hooks and any auditing in their setscheduler() hooks > seems very unpleasant anyway. I'd actually favor one of: > - Fix John's setscheduler patch to hold the lock while extracting > p->policy, drop it for the security checks, re-take the lock, and verify > that p->policy hasn't changed (if it has, bail with EPERM, as I can't > see any legitimate reason for such a race other than an intentional > malicious attempt to exploit it), or sigh it seems I posted the wrong patch file the one that got posted is the one where I threw up my hands and swore about having to break the lock as Stephan suggests. The actual patch adds an extra lock (I liked that a little better than breaking the rq lock) in setscheduler and around the other points that call __setschedule. > - Add a separate post hook to setscheduler after locks are dropped, and > do all auditing from it. Likely requires changing existing setscheduler > hook to return some state to pass along to the post hook for auditing in > addition to the error code itself. > This wouldn't be to bad but I would rather be able to use the audit frame work and printk from any lsm hook. jj
This archive was generated by hypermail 2.1.3 : Wed Oct 20 2004 - 09:02:57 PDT