From: =?utf-8?Q?Bj=C3=B8rn_Mork?= <bjorn@mork.no>
To: Oliver Neukum <oneukum@suse.com>
Cc: wmealing <wmealing@redhat.com>, linux-audit@redhat.com,
        linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org
Subject: Re: [RFC] Create an audit record of USB specific details
Organization: m
References: <1459742562-22803-1-git-send-email-wmail@redhat.com>
	<1459752519.24025.5.camel@suse.com>
Date: Mon, 04 Apr 2016 09:47:06 +0200
In-Reply-To: <1459752519.24025.5.camel@suse.com> (Oliver Neukum's message of
	"Mon, 04 Apr 2016 08:48:39 +0200")
Message-ID: <87bn5pzuh1.fsf@nemi.mork.no>
User-Agent: Gnus/5.130015 (Ma Gnus v0.15) Emacs/24.5 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8BIT
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2379
Lines: 53

Oliver Neukum <oneukum@suse.com> writes:
> On Mon, 2016-04-04 at 00:02 -0400, wmealing wrote:
>
>> I'm looking to create an audit trail for when devices are added or removed
>> from the system.
>> 
>> The audit subsystem is a logging subsystem in kernel space that can be
>> used to create advanced filters on generated events.  It has partnered userspace
>> utilities ausearch, auditd, aureport, auditctl which work exclusively on audit
>> records.
>> 
>> These tools are able to set filters to "trigger" on specific in-kernel events
>> specified by privileged users.  While the userspace tools can create audit 
>> events these are not able to be handled intelligently (decoded,filtered or 
>> ignored) as kernel generated audit events are.
>
> That is a goal that should be debated in general.

Yes.

And I think it would make this proposal appear a lot less fishy if it
included links and summaries of previous discussions on the subject. Is
there an assumption that people on this list remember every discussion
for weeks?  Or the opposite maybe?

AFAICS, Greg has already asked the obvious questions and made the
obvious "do this in userspace using the existing uevents" proposal. I
did not see any followup to his last message, so I assumed this audit
thing would return to the drawing board with a userspace implementation:
http://www.spinics.net/lists/linux-usb/msg137671.html

It was quite suprising to instead see a USB specific kernel
implemenation duplicating exisiting device add/remove functionality.
Why?  The provided reason makes absolutely no sense at all. Userspace
tools are as intelligent as you make them. And "decoded,filtered or
ignored" implies policy, which IMHO has no place in the kernel in any
case.

>> I have this working at the moment with the USB subsystem (as an example).
>> Its been suggested that I use systemd-udev however this means that the audit
>> tools (ausearch) will not be able to index these records.
>
> Chaining this so tightly to the USB subsystem makes no sense.
> If you do this, then please hook into the generic layer, that
> is add_device(), and provide a method in the generic device structure
> for providing information to the audit subsystem.

I think the generic layer implementation is already there.  The proposed
USB specific solution adds nothing, as pointed out by Greg the last time
this was discussed.


Bjørn