On 2019-01-17 10:05, Richard Guy Briggs wrote: > On 2019-01-17 10:32, Steve Grubb wrote: > > On Mon, 14 Jan 2019 17:58:58 -0500 > > Paul Moore <[email protected]> wrote: > > > > > On Mon, Dec 10, 2018 at 5:18 PM Richard Guy Briggs <[email protected]> > > > wrote: > > > > > > > > Tie syscall information to all CONFIG_CHANGE calls since they are > > > > all a result of user actions. > > > > Please don't tie syscall information to this. The syscall will be > > sendto. We don't need that information, its implicit. Also, doing this > > will possibly wreck things in libauparse. Please test the events with > > ausearch --format csv and --format text. IFF the event looks better or > > the same should we do this. If stuff disappears, the patch is > > breaking things > > Steve, I hope you aren't talking about the AUDIT_*USER* records, because > this patch intentionally leaves them unassociated with the syscall > record. > > The config change records are related.
The association of all AUDIT_CONFIG_CHANGE records with syscall records provides subject attributes that are missing from several of the different AUDIT_CONFIG_CHANGE records. audit_mark_log_rule_change missing: subj audit_tree_log_remove_rule missing: auid, ses, subj audit_watch_log_rule_change missing: subj audit_seccomp_actions_logged missing: auid, ses, subj > > -Steve > > > > > > Exclude user records from syscall context: > > > > Since the function audit_log_common_recv_msg() is shared by a > > > > number of AUDIT_CONFIG_CHANGE and the entire range of AUDIT_USER_* > > > > record types, and since the AUDIT_CONFIG_CHANGE message type has > > > > been converted to a syscall accompanied record type, special-case > > > > the AUDIT_USER_* range of messages so they remain standalone > > > > records. > > > > > > > > See: https://github.com/linux-audit/audit-kernel/issues/59 > > > > See: https://github.com/linux-audit/audit-kernel/issues/50 > > > > Signed-off-by: Richard Guy Briggs <[email protected]> > > > > --- > > > > kernel/audit.c | 27 +++++++++++++++++++-------- > > > > kernel/audit_fsnotify.c | 2 +- > > > > kernel/audit_tree.c | 2 +- > > > > kernel/audit_watch.c | 2 +- > > > > kernel/auditfilter.c | 2 +- > > > > 5 files changed, 23 insertions(+), 12 deletions(-) > > > > > > > > diff --git a/kernel/audit.c b/kernel/audit.c > > > > index 0e8026423fbd..a321fea94cc6 100644 > > > > --- a/kernel/audit.c > > > > +++ b/kernel/audit.c > > > > @@ -1072,6 +1073,16 @@ static void audit_log_common_recv_msg(struct > > > > audit_buffer **ab, u16 msg_type) audit_log_task_context(*ab); > > > > } > > > > > > > > +static inline void audit_log_user_recv_msg(struct audit_buffer > > > > **ab, u16 msg_type) +{ > > > > + audit_log_common_recv_msg(NULL, ab, msg_type); > > > > +} > > > > > > This makes sense because this is used by "user" records ... > > > > > > > +static inline void audit_log_config_change_alt(struct audit_buffer > > > > **ab) +{ > > > > + audit_log_common_recv_msg(audit_context(), ab, > > > > AUDIT_CONFIG_CHANGE); +} > > > > > > ... and I don't believe this makes sense because there is no real > > > logical grouping with the callers like there is for > > > audit_log_user_recv_msg(). > > - RGB - RGB -- Richard Guy Briggs <[email protected]> Sr. S/W Engineer, Kernel Security, Base Operating Systems Remote, Ottawa, Red Hat Canada IRC: rgb, SunRaycer Voice: +1.647.777.2635, Internal: (81) 32635 -- Linux-audit mailing list [email protected] https://www.redhat.com/mailman/listinfo/linux-audit
