On 15/08/06, Paul Moore wrote:
On August 6, 2015 5:11:50 PM Steve Grubb <sgrubb(a)redhat.com>
wrote:
>On Thursday, August 06, 2015 04:24:58 PM Paul Moore wrote:
>> On Wednesday, August 05, 2015 04:29:38 PM Richard Guy Briggs wrote:
>> > This adds the ability to audit the actions of children of a
>> > not-yet-running
>> > process.
>> >
>> >
>> >
>> > This is a split-out of a heavily modified version of a patch originally
>> > submitted by Eric Paris with some ideas from Peter Moody.
>> >
>> >
>> >
>> > Cc: Peter Moody <peter(a)hda3.com>
>> > Cc: Eric Paris <eparis(a)redhat.com>
>> > Signed-off-by: Richard Guy Briggs <rgb(a)redhat.com>
>> > ---
>> >
>> > include/uapi/linux/audit.h | 1 +
>> > kernel/auditfilter.c | 5 +++++
>> > kernel/auditsc.c | 11 +++++++++++
>> > 3 files changed, 17 insertions(+), 0 deletions(-)
>>
>> I'm still not really comfortable with that loop and since there hasn't
been
>> a really convincing use case I'm going to pass on this patch for right
>> now. If someone comes up with a *really* compelling case in the future
>> I'll reconsider it.
>
>Its the same reason strace has a -f option. Sometimes you need to also see
>what the children did. For example, maybe you want to audit file access to a
>specific directory and several cgi-bin programs can get there. You could write
>a rule for apache and be done. Or maybe, you have an app that lets people have
>shell access and you need to see files accessed or connections opened. Or maybe
>its a control panel application with helper scripts and you need to see
>changes that its making. Or maybe you have a program that is at risk of being
>compromised and you want to see if someone gets a shell from it. There are a
>lot of cases where it could be useful.
>
>-Steve
>
>--
>Linux-audit mailing list
>Linux-audit(a)redhat.com
>https://www.redhat.com/mailman/listinfo/linux-audit
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.
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