Re: [PATCH ghak105 V2] audit: remove audit_context when CONFIG_ AUDIT and not AUDITSYSCALL

On Tue, Jan 29, 2019 at 9:54 PM Richard Guy Briggs <rgb(a)redhat.com&gt; wrote: > On 2019-01-29 18:26, Paul Moore wrote: > > On Tue, Jan 29, 2019 at 6:18 PM Richard Guy Briggs <rgb(a)redhat.com&gt; wrote: > > > On 2019-01-29 18:07, Paul Moore wrote: > > > > On Mon, Jan 28, 2019 at 1:33 PM Richard Guy Briggs <rgb(a)redhat.com&gt; wrote: > > > > > Remove audit_context from struct task_struct and struct audit_buffer > > > > > when CONFIG_AUDIT is enabled but CONFIG_AUDITSYSCALL is not. > > > > > > > > > > Also, audit_log_name() (and supporting inode and fcaps functions) should > > > > > have been put back in auditsc.c when soft and hard link logging was > > > > > normalized since it is only used by syscall auditing. > > > > > > > > > > See github issue https://github.com/linux-audit/audit-kernel/issues/105 > > > > > > > > > > Signed-off-by: Richard Guy Briggs <rgb(a)redhat.com&gt; > > > > > --- > > > > > Changelog: > > > > > v2: > > > > > - resolve merge conflicts from rebase on upstreamed ghak103 patch > > > > > - wrap task_struct audit_context in CONFIG_AUDITSYSCALL > > > > > > > > > > include/linux/sched.h | 4 +- > > > > > kernel/audit.c | 157 +++----------------------------------------------- > > > > > kernel/audit.h | 9 --- > > > > > kernel/auditsc.c | 150 +++++++++++++++++++++++++++++++++++++++++++++++ > > > > > 4 files changed, 161 insertions(+), 159 deletions(-) > > > > > > > > ... > > > > > > > > > diff --git a/kernel/audit.c b/kernel/audit.c > > > > > index 3f3f1888cac7..15e41603fd34 100644 > > > > > --- a/kernel/audit.c > > > > > +++ b/kernel/audit.c > > > > > @@ -205,7 +205,9 @@ struct audit_net { > > > > > * use simultaneously. */ > > > > > struct audit_buffer { > > > > > struct sk_buff *skb; /* formatted skb ready to send */ > > > > > +#ifdef CONFIG_AUDITSYSCALL > > > > > struct audit_context *ctx; /* NULL or associated context */ > > > > > +#endif > > > > > gfp_t gfp_mask; > > > > > }; > > > > > > > > > > @@ -1696,7 +1698,9 @@ static struct audit_buffer *audit_buffer_alloc(struct audit_context *ctx, > > > > > if (!nlmsg_put(ab->skb, 0, 0, type, 0, 0)) > > > > > goto err; > > > > > > > > > > +#ifdef CONFIG_AUDITSYSCALL > > > > > ab->ctx = ctx; > > > > > +#endif > > > > > > > > I vaguely remember reading/hearing something in the past about > > > > kmem_cache_alloc() not returning a zero'd out buffer in all cases, can > > > > you say for certain that "ab" in this case is always going to be > > > > zero'd out? This is an honest question. > > > > > > Ok, then maybe we should be using kmem_cache_zalloc() instead of > > > kmem_cache_alloc() in audit_buffer_alloc()? (as I've done in > > > the last patch of ghak81/first patch of ghak90) > > > > > > If this is too much overhead, then we can initialize ctx = NULL; > > > > We don't need zalloc() since we're setting all the fields, although > > more on this below ... > > Ok... > > > > > If we can't guarantee that "ab" is zero'd out, we should manually set > > > > ab->ctx to NULL when !CONFIG_AUDITSYSCALL. > > > > > > But ctx isn't part of struct audit_buffer when !CONFIG_AUDITSYSCALL. It > > > is #ifdef-ed out. What am I missing? > > > > You're not, I am. I saw the obvious bit where you removed it from the > > task_struct, but completely glossed over the bit where you also > > removed it from the audit_buffer struct. My mistake. > > > > Once the audit container ID stuff lands we are going to need to have > > the audit_context pointer in the audit_buffer regardless of the > > CONFIG_AUDITSYSCALL setting, right? Assuming the answer is yes, I > > think I'd just assume leave the pointer in the audit_buffer (setting > > it to NULL when !CONFIG_AUDITSYSCALL) so we don't have to have those > > #ifdef's in the middle of the functions (I generally like to avoid > > those if possible). I think it's still worth making the changes to > > task_struct, as that is the right thing to do and doesn't have the > > same level of impact. > > I like to avoid #ifdef compiler directives out when I can too, creating > stubs in the header file to do the job. > > Why do we need an audit_context pointer in struct audit_buffer? I'll > take a stab at answering this... I was thinking it wasn't necessary, > but now I think I see what I was missing. I think the only reason is to > connect records to one event through the timestamp and serial number > when syscall is disabled. Up until now it wasn't needed unless full > syscall functionality was present, but once we have an audit container > identifier aux record we will need to join them, at minimum with a local > context for user and netfilter_pkt records. I also expect us the significance to grow over time as we start to deal with the event routing problem; one solution would be to track the audit container ID as a field in the audit_context. Basically I see the audit_context as the audit "event" data structure where the audit_buffer is the audit "record" data structure. Their use doesn't always line up perfectly with those definitions at present, but I tend to think of the deviations as problems to correct over time. > So I have to ask, does it make sense to restructure things so that the > struct audit_buffer has a serial and ctime field so that it isn't needed > in the struct audit_context? I'm not sure if this is possible. I'll > have to go back and look at the code to see if this is the case... I would say "no" if for no other reason than what I said about about the audit_context being the "event" data structure.