linux-kernel - Re: [PATCH ghak59 V3 2/4] audit: add syscall information to CONFIG

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20190117170815.40131a69@ivy-bridge>
Date:   Thu, 17 Jan 2019 17:08:15 +0100
From:   Steve Grubb <sgrubb@...hat.com>
To:     Paul Moore <paul@...l-moore.com>
Cc:     Richard Guy Briggs <rgb@...hat.com>,
        LKML <linux-kernel@...r.kernel.org>,
        Linux-Audit Mailing List <linux-audit@...hat.com>,
        Eric Paris <eparis@...hat.com>,
        Alexander Viro <viro@...iv.linux.org.uk>
Subject: Re: [PATCH ghak59 V3 2/4] audit: add syscall information to
 CONFIG_CHANGE records

On Thu, 17 Jan 2019 08:21:40 -0500
Paul Moore <paul@...l-moore.com> wrote:

> On Thu, Jan 17, 2019 at 4:33 AM Steve Grubb <sgrubb@...hat.com> wrote:
> > On Mon, 14 Jan 2019 17:58:58 -0500
> > Paul Moore <paul@...l-moore.com> wrote:
> >  
> > > On Mon, Dec 10, 2018 at 5:18 PM Richard Guy Briggs
> > > <rgb@...hat.com> 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  
> 
> We've discussed this quite a bit already;

Yes, and you still don't seem be listening. You have to cooperate on
modifying events. We as a community need to respect each other's needs
and work together to solve problems. What this is saying sounds a lot
like I don't care if it breaks things, I'm gonna do it my way. Tough
luck.

You do not have to make sense of any of these events. So, what does it
really matter to you how the event is formed? What I'm asking for is
have these changes been vetted to ensure that they are not breaking
things?

> connecting associated records into a single event is something that
> should happen, needs to happen, and will happen.  Conceptually it
> makes no sense to record the syscall (and any other associated
> records) which triggers the audit configuration change, and the
> configuration change record itself as two distinct events - they are
> the same event.

Except that they are not. The design of the audit system is to save
disk space as much as possible by emitting single record events on
certain event types that are simple. To add a syscall to it adds useless
information (such as a socket address record), slows down processing,
and wastes disk space. If you get a SYSCALL record, that indicates that
you have triggered an event that the system admin has placed explicit
rules on. That is different than the common criteria required
configuration change event. 

>  We've also heard from a prominent user that
> associating records in this way is desirable.
> 
> If the ausearch csv and text audit log transformations can't handle
> this particular change, I would consider that a shortcoming of that
> code.  We have multi-record events now, and this is only going to
> increase in the future.

Isn't there some kind a guideline about not breaking user space?

-Steve

> Richard, if you can't make the requested changes to this patch and
> resubmit by ... let's say the middle of next week? that should be
> enough time, yes? ... please let me know and I'll make the changes and
> get this merged.
>