On 15/08/07, Paul Moore wrote:
On Friday, August 07, 2015 02:37:15 AM Richard Guy Briggs wrote:
> On 15/08/06, Paul Moore wrote:
>
> > I guess what I'm saying is that I'm not currently convinced that
> > there is enough value in this to offset the risk I feel the loop
> > presents. I understand the use cases that you are mentioning, the
> > are the same as the last time we discussed this, but I'm going to
> > need something better than that.
>
> Can you better describe the loop that concerns you? I don't quite see
> it.
It would be the only loop in the patch, look at the for loop in
audit_filter_rules() which iterates up the process' parent chain.
Sorry, I should reword that... What risk do you see in that loop? It
works up the task ancestry tree until it triggers, or hits init for that
PID namespace that terminates the loop. Do you see a risk in the
numerical pids rolling underneath the loop?
I *do* notice that find_task_by_vpid(pid_t) must be replaced with
find_task_by_pid_ns(pid_t, &init_pid_ns), since task_struct->pid is
always stored in the initial PID namespace.
paul moore
- RGB
--
Richard Guy Briggs <rbriggs(a)redhat.com>
Senior Software Engineer, Kernel Security, AMER ENG Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.693.0684x3545