* Re: [RFC] Create an audit record of USB specific details
From: Alan Stern @ 2016-04-05 14:40 UTC (permalink / raw)
To: Wade Mealing
Cc: Bjørn Mork, Oliver Neukum, linux-audit, linux-kernel,
linux-usb
In-Reply-To: <CALJHwhR5FQaa6v=ZPyLRZ8L+OrucXqEiwe6QE43HybM2keErYg@mail.gmail.com>
On Tue, 5 Apr 2016, Wade Mealing wrote:
> I'm reframing my use case as follows to try and better explain the
> situation I am trying to track.
>
> It might seem that I am duplicating existing functionality, rather I
> am trying to augment functionality that seems to be
> unavailable.Replication of existing functionality is not my intention.
>
> Consider the following scenario. Currently we have device drivers
> that emit text via a printk request which is eventually picked up by
> syslog like implementation (not the audit subsystem).
>
> The goal of these message is to let a system administrator see in the
> audit logs, that a device has been plugged in and the basic details
> about this. Having this only in userspace means that (and Greg
> alludes to this ) that this will be for human eyes only and not be
> machine usable in the kernels. Without it being in kernel, it can't
> be extended for manipulation by auditctl at some point in the future.
>
> Specifically I am trying to create a well formed audit trail when
> devices are added or removed from the system by the userspace audit
> tools. The implementation at the moment does not do any filtering,
> but rather creates the raw audit events.
>
> In some ways this is similar to a decorated class in say java. In
> this case the class is unaware it is being decorated yet we can
> monitor what is happening in that class without polluting the class
> code with messy log or trace information.
>
> I don't see either kernel or user-space applications create add or
> remove events in the audit subsystem. I understand that some events
> are placed into uevents (To be intercepted by udevd), while this also
> exports the same information it is not in the audit subsystem in
> kernel.
>
> > 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.
>
> I agree it would be ideal to use existing userspace or kernelspace
> facilities for auditing and not duplicating efforts, it seems that the
> specific case I am trying to track isn't covered. Maybe I missed it
> be can you indicate where device add/remove audit (not log messages)
> are being generated/implemented in the kernel or userspace for the
> scenario I described?
If you want a place in the kernel to add audit records for all devices
added to or removed from the system, the right place to do it is in
drivers/base/core.c, the device_add() and device_del() routines.
That's where the ADD and REMOVE uevents are created.
Alan Stern
^ permalink raw reply
* RE: EXT :Re: [RFC] Create an audit record of USB specific details
From: Burn Alting @ 2016-04-05 14:37 UTC (permalink / raw)
To: Boyce, Kevin P (AS)
Cc: Greg KH, linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-audit-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org
In-Reply-To: <9dd2354558314ead819366b954e97133-cZmdoFAsBjDgAiKnVY1dJgQSgKfZeEaX@public.gmane.org>
On Tue, 2016-04-05 at 14:20 +0000, Boyce, Kevin P (AS) wrote:
> In all of this discussion about auditing insertion and removal of usb devices, I would mention that you'd want a complete solution, not just USB.
> If you are trying to prevent people from stealing data or know what data they stole (as in the case of Eric Snowden and Brad Manning) I would think you would be concerned with Firewire, CDROM/DVD/Blu Ray, Tape, printer, and other devices one could use for espionage.
>
> Perhaps you would also want to document in the audit system what file operations were performed on the file system of the rogue device. These become very difficult tid bits of information to produce, especially considering all of the ways one could use to write to a device.
>
Hence my final comment below about well known devices and the desire
monitor open/openat/etc for write system calls on 'deemed removable
media' ie one day we could set up
auditctl -F arch=b64 -a always,exit -S open -F a1&3 -F dev=removable
-k RMopen
Burn
> Kevin
>
> -----Original Message-----
> From: linux-audit-bounces-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org [mailto:linux-audit-bounces-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org] On Behalf Of Burn Alting
> Sent: Tuesday, April 05, 2016 10:08 AM
> To: Greg KH
> Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linux-audit-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org
> Subject: EXT :Re: [RFC] Create an audit record of USB specific details
>
> On Tue, 2016-04-05 at 09:44 -0400, Greg KH wrote:
> > On Tue, Apr 05, 2016 at 11:07:48PM +1000, Burn Alting wrote:
> > > On Mon, 2016-04-04 at 14:53 -0700, Greg KH wrote:
> > > > On Mon, Apr 04, 2016 at 02:48:43PM -0700, Greg KH wrote:
> > > > > On Mon, Apr 04, 2016 at 05:33:10PM -0400, Steve Grubb wrote:
> > > > > > On Monday, April 04, 2016 05:56:26 AM Greg KH wrote:
> > > > > > > On Mon, Apr 04, 2016 at 12:02:42AM -0400, wmealing wrote:
> > > > > > > > From: Wade Mealing <wmealing-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> > > > > > > >
> > > > > > > > Gday,
> > > > > > > >
> > > > > > > > I'm looking to create an audit trail for when devices are
> > > > > > > > added or removed from the system.
> > > > > > >
> > > > > > > Then please do it in userspace, as I suggested before, that
> > > > > > > way you catch all types of devices, not just USB ones.
> > > > > > >
> > > > > > > Also I don't think you realize that USB interfaces are what
> > > > > > > are bound to drivers, not USB devices, so that is going to
> > > > > > > mess with any attempted audit trails here. How are you
> > > > > > > going to distinguish between the 5 different devices that
> > > > > > > just got plugged in that all have 0000/0000 as vid/pid for
> > > > > > > them because they are "cheap" devices from China, yet do totally different things because they are different _types_ of devices?
> > > > > >
> > > > > > This sounds like vid/pid should be captured in the event.
> > > > >
> > > > > The code did that, the point is, vid/pid means nothing in the
> > > > > real world. So why are you going to audit anything based on it?
> > > > > :)
> > > >
> > > > Oh wait, it's worse, it is logging strings, which are even more
> > > > unreliable than vid/pid values. It's pretty obvious this has not
> > > > been tested on any large batch of real-world devices, or thought
> > > > through as to why any of this is even needed at all.
> > > >
> > > > So why is this being added? Who needs/wants this? What are their
> > > > requirements here?
> > >
> > > As a consumer of auditd events for security purposes, the questions
> > > I would like answered via the sort of audit framework Wade is
> > > putting together are
> > >
> > > - when was a (possible) removable media device plugged into a system
> > > and what were the device details - perhaps my corporation has a
> > > policy on what devices are 'official' and hence one looks for
> > > alternatives, and/or,
> >
> > How do you determine if a USB device is "official" or not? What
> > attribute(s) are you going to care about that can't be trivially
> > spoofed?
>
> One typically can't defeat the knowledgeable and determined person, but this doesn't mean you don't try. In the windows world, most DLP capabilities make use of Manufacturer/Model/Serial in combination with user and system to determine/record access. In the case of Linux audit, we would be closing the gate after the horse has bolted, but at least we know it has occurred.
>
> >
> > > - was it there at boot ? (in case someone adds and removes such
> > > devices when powered off), and eventually
> >
> > What if you booted off of it?
>
> Which means audit could be defeated anyway since one controls the OS, but again one still needs to try.
>
> >
> > > - has an open for write (or other system calls) occurred on
> > > designated removable media? (i.e. what may have been written to
> > > removable media - cooked or raw) - Yes, this infers a baseline of
> > > what's connected or an efficient means of working out if a device is
> > > 'removable' at system call time.
> >
> > Yes, determining "removable" is non-trivial, good luck with that :)
>
> I was hoping for a configurable table that could be pre-seeded and either managed via the audit interface (add/delete/masked). Pre-seed with well known devices such as cd/dvd, usb mass storage, scsi devices with the RMB bit set, etc and go from there. We need to start somewhere ...
>
>
> >
> > thanks,
> >
> > greg k-h
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* RE: EXT :Re: [RFC] Create an audit record of USB specific details
From: Boyce, Kevin P (AS) @ 2016-04-05 14:20 UTC (permalink / raw)
To: burn@swtf.dyndns.org, Greg KH
Cc: linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org,
linux-audit@redhat.com
In-Reply-To: <1459865304.7998.102.camel@swtf.swtf.dyndns.org>
In all of this discussion about auditing insertion and removal of usb devices, I would mention that you'd want a complete solution, not just USB.
If you are trying to prevent people from stealing data or know what data they stole (as in the case of Eric Snowden and Brad Manning) I would think you would be concerned with Firewire, CDROM/DVD/Blu Ray, Tape, printer, and other devices one could use for espionage.
Perhaps you would also want to document in the audit system what file operations were performed on the file system of the rogue device. These become very difficult tid bits of information to produce, especially considering all of the ways one could use to write to a device.
Kevin
-----Original Message-----
From: linux-audit-bounces@redhat.com [mailto:linux-audit-bounces@redhat.com] On Behalf Of Burn Alting
Sent: Tuesday, April 05, 2016 10:08 AM
To: Greg KH
Cc: linux-kernel@vger.kernel.org; linux-usb@vger.kernel.org; linux-audit@redhat.com
Subject: EXT :Re: [RFC] Create an audit record of USB specific details
On Tue, 2016-04-05 at 09:44 -0400, Greg KH wrote:
> On Tue, Apr 05, 2016 at 11:07:48PM +1000, Burn Alting wrote:
> > On Mon, 2016-04-04 at 14:53 -0700, Greg KH wrote:
> > > On Mon, Apr 04, 2016 at 02:48:43PM -0700, Greg KH wrote:
> > > > On Mon, Apr 04, 2016 at 05:33:10PM -0400, Steve Grubb wrote:
> > > > > On Monday, April 04, 2016 05:56:26 AM Greg KH wrote:
> > > > > > On Mon, Apr 04, 2016 at 12:02:42AM -0400, wmealing wrote:
> > > > > > > From: Wade Mealing <wmealing@redhat.com>
> > > > > > >
> > > > > > > Gday,
> > > > > > >
> > > > > > > I'm looking to create an audit trail for when devices are
> > > > > > > added or removed from the system.
> > > > > >
> > > > > > Then please do it in userspace, as I suggested before, that
> > > > > > way you catch all types of devices, not just USB ones.
> > > > > >
> > > > > > Also I don't think you realize that USB interfaces are what
> > > > > > are bound to drivers, not USB devices, so that is going to
> > > > > > mess with any attempted audit trails here. How are you
> > > > > > going to distinguish between the 5 different devices that
> > > > > > just got plugged in that all have 0000/0000 as vid/pid for
> > > > > > them because they are "cheap" devices from China, yet do totally different things because they are different _types_ of devices?
> > > > >
> > > > > This sounds like vid/pid should be captured in the event.
> > > >
> > > > The code did that, the point is, vid/pid means nothing in the
> > > > real world. So why are you going to audit anything based on it?
> > > > :)
> > >
> > > Oh wait, it's worse, it is logging strings, which are even more
> > > unreliable than vid/pid values. It's pretty obvious this has not
> > > been tested on any large batch of real-world devices, or thought
> > > through as to why any of this is even needed at all.
> > >
> > > So why is this being added? Who needs/wants this? What are their
> > > requirements here?
> >
> > As a consumer of auditd events for security purposes, the questions
> > I would like answered via the sort of audit framework Wade is
> > putting together are
> >
> > - when was a (possible) removable media device plugged into a system
> > and what were the device details - perhaps my corporation has a
> > policy on what devices are 'official' and hence one looks for
> > alternatives, and/or,
>
> How do you determine if a USB device is "official" or not? What
> attribute(s) are you going to care about that can't be trivially
> spoofed?
One typically can't defeat the knowledgeable and determined person, but this doesn't mean you don't try. In the windows world, most DLP capabilities make use of Manufacturer/Model/Serial in combination with user and system to determine/record access. In the case of Linux audit, we would be closing the gate after the horse has bolted, but at least we know it has occurred.
>
> > - was it there at boot ? (in case someone adds and removes such
> > devices when powered off), and eventually
>
> What if you booted off of it?
Which means audit could be defeated anyway since one controls the OS, but again one still needs to try.
>
> > - has an open for write (or other system calls) occurred on
> > designated removable media? (i.e. what may have been written to
> > removable media - cooked or raw) - Yes, this infers a baseline of
> > what's connected or an efficient means of working out if a device is
> > 'removable' at system call time.
>
> Yes, determining "removable" is non-trivial, good luck with that :)
I was hoping for a configurable table that could be pre-seeded and either managed via the audit interface (add/delete/masked). Pre-seed with well known devices such as cd/dvd, usb mass storage, scsi devices with the RMB bit set, etc and go from there. We need to start somewhere ...
>
> thanks,
>
> greg k-h
^ permalink raw reply
* Re: [RFC] Create an audit record of USB specific details
From: Burn Alting @ 2016-04-05 14:08 UTC (permalink / raw)
To: Greg KH; +Cc: linux-kernel, linux-usb, linux-audit
In-Reply-To: <20160405134427.GB31313@kroah.com>
On Tue, 2016-04-05 at 09:44 -0400, Greg KH wrote:
> On Tue, Apr 05, 2016 at 11:07:48PM +1000, Burn Alting wrote:
> > On Mon, 2016-04-04 at 14:53 -0700, Greg KH wrote:
> > > On Mon, Apr 04, 2016 at 02:48:43PM -0700, Greg KH wrote:
> > > > On Mon, Apr 04, 2016 at 05:33:10PM -0400, Steve Grubb wrote:
> > > > > On Monday, April 04, 2016 05:56:26 AM Greg KH wrote:
> > > > > > On Mon, Apr 04, 2016 at 12:02:42AM -0400, wmealing wrote:
> > > > > > > From: Wade Mealing <wmealing@redhat.com>
> > > > > > >
> > > > > > > Gday,
> > > > > > >
> > > > > > > I'm looking to create an audit trail for when devices are added or removed
> > > > > > > from the system.
> > > > > >
> > > > > > Then please do it in userspace, as I suggested before, that way you
> > > > > > catch all types of devices, not just USB ones.
> > > > > >
> > > > > > Also I don't think you realize that USB interfaces are what are bound to
> > > > > > drivers, not USB devices, so that is going to mess with any attempted
> > > > > > audit trails here. How are you going to distinguish between the 5
> > > > > > different devices that just got plugged in that all have 0000/0000 as
> > > > > > vid/pid for them because they are "cheap" devices from China, yet do
> > > > > > totally different things because they are different _types_ of devices?
> > > > >
> > > > > This sounds like vid/pid should be captured in the event.
> > > >
> > > > The code did that, the point is, vid/pid means nothing in the real
> > > > world. So why are you going to audit anything based on it? :)
> > >
> > > Oh wait, it's worse, it is logging strings, which are even more
> > > unreliable than vid/pid values. It's pretty obvious this has not been
> > > tested on any large batch of real-world devices, or thought through as
> > > to why any of this is even needed at all.
> > >
> > > So why is this being added? Who needs/wants this? What are their
> > > requirements here?
> >
> > As a consumer of auditd events for security purposes, the questions I
> > would like answered via the sort of audit framework Wade is putting
> > together are
> >
> > - when was a (possible) removable media device plugged into a system and
> > what were the device details - perhaps my corporation has a policy on
> > what devices are 'official' and hence one looks for alternatives,
> > and/or,
>
> How do you determine if a USB device is "official" or not? What
> attribute(s) are you going to care about that can't be trivially
> spoofed?
One typically can't defeat the knowledgeable and determined person, but
this doesn't mean you don't try. In the windows world, most DLP
capabilities make use of Manufacturer/Model/Serial in combination with
user and system to determine/record access. In the case of Linux audit,
we would be closing the gate after the horse has bolted, but at least we
know it has occurred.
>
> > - was it there at boot ? (in case someone adds and removes such devices
> > when powered off), and eventually
>
> What if you booted off of it?
Which means audit could be defeated anyway since one controls the OS,
but again one still needs to try.
>
> > - has an open for write (or other system calls) occurred on designated
> > removable media? (i.e. what may have been written to removable media -
> > cooked or raw) - Yes, this infers a baseline of what's connected or an
> > efficient means of working out if a device is 'removable' at system call
> > time.
>
> Yes, determining "removable" is non-trivial, good luck with that :)
I was hoping for a configurable table that could be pre-seeded and
either managed via the audit interface (add/delete/masked). Pre-seed
with well known devices such as cd/dvd, usb mass storage, scsi devices
with the RMB bit set, etc and go from there. We need to start
somewhere ...
>
> thanks,
>
> greg k-h
^ permalink raw reply
* RE: EXT :Re: [RFC] Create an audit record of USB specific details
From: Boyce, Kevin P (AS) @ 2016-04-05 13:52 UTC (permalink / raw)
To: Greg KH
Cc: Wade Mealing, Bjørn Mork, Oliver Neukum,
linux-kernel@vger.kernel.org, linux-usb, linux-audit@redhat.com
In-Reply-To: <20160405134632.GC31313@kroah.com>
Greg,
> There is no "/proc/usb/" :)
Sorry, maybe /sys/bus/usb/devices was what I was looking for...
> The kernel calls mknod itself on devtmpfs, userspace doesn't do that anymore (hasn't for a long time). Do you get those audit events today?
I'm not auditing those events myself. Just proposing ideas that might produce the sort of information Wade was looking for.
kevin
^ permalink raw reply
* Re: EXT :Re: [RFC] Create an audit record of USB specific details
From: Greg KH @ 2016-04-05 13:46 UTC (permalink / raw)
To: Boyce, Kevin P (AS)
Cc: Wade Mealing, Bjørn Mork, Oliver Neukum,
linux-kernel@vger.kernel.org, linux-usb, linux-audit@redhat.com
In-Reply-To: <889498a2eca043d5af1fe23ffb574284@XCGVAG30.northgrum.com>
On Tue, Apr 05, 2016 at 11:49:14AM +0000, Boyce, Kevin P (AS) wrote:
> Wade,
>
> Wouldn't this imply that every time the system is booted and the PCI
> bus for example is enumerated and all of the devices are created that
> all of those activities generate audit events?
> That sounds less than desiriable. Does this imply that the audit
> subsystem should maintain a "baseline" of hardware that is always
> present on the system?
If you do, what happens when your PCI devices renumber themselves the
next time you boot (hint, PCI numbering is not static.)
> Couldn't you audit a directory under /proc/usb?
There is no "/proc/usb/" :)
> Correct me if I am wrong, but doesn't audititing of the syscall mknod
> create an event when devices are "added" to the system?
The kernel calls mknod itself on devtmpfs, userspace doesn't do that
anymore (hasn't for a long time). Do you get those audit events today?
thanks,
greg k-h
^ permalink raw reply
* Re: [RFC] Create an audit record of USB specific details
From: Greg KH @ 2016-04-05 13:44 UTC (permalink / raw)
To: Burn Alting; +Cc: Steve Grubb, linux-audit, linux-kernel, linux-usb
In-Reply-To: <1459861668.7998.92.camel@swtf.swtf.dyndns.org>
On Tue, Apr 05, 2016 at 11:07:48PM +1000, Burn Alting wrote:
> On Mon, 2016-04-04 at 14:53 -0700, Greg KH wrote:
> > On Mon, Apr 04, 2016 at 02:48:43PM -0700, Greg KH wrote:
> > > On Mon, Apr 04, 2016 at 05:33:10PM -0400, Steve Grubb wrote:
> > > > On Monday, April 04, 2016 05:56:26 AM Greg KH wrote:
> > > > > On Mon, Apr 04, 2016 at 12:02:42AM -0400, wmealing wrote:
> > > > > > From: Wade Mealing <wmealing@redhat.com>
> > > > > >
> > > > > > Gday,
> > > > > >
> > > > > > I'm looking to create an audit trail for when devices are added or removed
> > > > > > from the system.
> > > > >
> > > > > Then please do it in userspace, as I suggested before, that way you
> > > > > catch all types of devices, not just USB ones.
> > > > >
> > > > > Also I don't think you realize that USB interfaces are what are bound to
> > > > > drivers, not USB devices, so that is going to mess with any attempted
> > > > > audit trails here. How are you going to distinguish between the 5
> > > > > different devices that just got plugged in that all have 0000/0000 as
> > > > > vid/pid for them because they are "cheap" devices from China, yet do
> > > > > totally different things because they are different _types_ of devices?
> > > >
> > > > This sounds like vid/pid should be captured in the event.
> > >
> > > The code did that, the point is, vid/pid means nothing in the real
> > > world. So why are you going to audit anything based on it? :)
> >
> > Oh wait, it's worse, it is logging strings, which are even more
> > unreliable than vid/pid values. It's pretty obvious this has not been
> > tested on any large batch of real-world devices, or thought through as
> > to why any of this is even needed at all.
> >
> > So why is this being added? Who needs/wants this? What are their
> > requirements here?
>
> As a consumer of auditd events for security purposes, the questions I
> would like answered via the sort of audit framework Wade is putting
> together are
>
> - when was a (possible) removable media device plugged into a system and
> what were the device details - perhaps my corporation has a policy on
> what devices are 'official' and hence one looks for alternatives,
> and/or,
How do you determine if a USB device is "official" or not? What
attribute(s) are you going to care about that can't be trivially
spoofed?
> - was it there at boot ? (in case someone adds and removes such devices
> when powered off), and eventually
What if you booted off of it?
> - has an open for write (or other system calls) occurred on designated
> removable media? (i.e. what may have been written to removable media -
> cooked or raw) - Yes, this infers a baseline of what's connected or an
> efficient means of working out if a device is 'removable' at system call
> time.
Yes, determining "removable" is non-trivial, good luck with that :)
thanks,
greg k-h
^ permalink raw reply
* Re: [RFC] Create an audit record of USB specific details
From: Burn Alting @ 2016-04-05 13:07 UTC (permalink / raw)
To: Greg KH; +Cc: Steve Grubb, linux-audit, linux-kernel, linux-usb
In-Reply-To: <20160404215302.GC26580@kroah.com>
On Mon, 2016-04-04 at 14:53 -0700, Greg KH wrote:
> On Mon, Apr 04, 2016 at 02:48:43PM -0700, Greg KH wrote:
> > On Mon, Apr 04, 2016 at 05:33:10PM -0400, Steve Grubb wrote:
> > > On Monday, April 04, 2016 05:56:26 AM Greg KH wrote:
> > > > On Mon, Apr 04, 2016 at 12:02:42AM -0400, wmealing wrote:
> > > > > From: Wade Mealing <wmealing@redhat.com>
> > > > >
> > > > > Gday,
> > > > >
> > > > > I'm looking to create an audit trail for when devices are added or removed
> > > > > from the system.
> > > >
> > > > Then please do it in userspace, as I suggested before, that way you
> > > > catch all types of devices, not just USB ones.
> > > >
> > > > Also I don't think you realize that USB interfaces are what are bound to
> > > > drivers, not USB devices, so that is going to mess with any attempted
> > > > audit trails here. How are you going to distinguish between the 5
> > > > different devices that just got plugged in that all have 0000/0000 as
> > > > vid/pid for them because they are "cheap" devices from China, yet do
> > > > totally different things because they are different _types_ of devices?
> > >
> > > This sounds like vid/pid should be captured in the event.
> >
> > The code did that, the point is, vid/pid means nothing in the real
> > world. So why are you going to audit anything based on it? :)
>
> Oh wait, it's worse, it is logging strings, which are even more
> unreliable than vid/pid values. It's pretty obvious this has not been
> tested on any large batch of real-world devices, or thought through as
> to why any of this is even needed at all.
>
> So why is this being added? Who needs/wants this? What are their
> requirements here?
As a consumer of auditd events for security purposes, the questions I
would like answered via the sort of audit framework Wade is putting
together are
- when was a (possible) removable media device plugged into a system and
what were the device details - perhaps my corporation has a policy on
what devices are 'official' and hence one looks for alternatives,
and/or,
- was it there at boot ? (in case someone adds and removes such devices
when powered off), and eventually
- has an open for write (or other system calls) occurred on designated
removable media? (i.e. what may have been written to removable media -
cooked or raw) - Yes, this infers a baseline of what's connected or an
efficient means of working out if a device is 'removable' at system call
time.
In essence, I need to know if and how removable media is being used on
my systems. The definition of 'removable' is challenging, but my idea
would be for one to be able to define it via the auditd interface.
> From what I recall, the author is just messing
> around with the USB subsystem and audit as something fun to do, which is
> great, but don't expect it to be mergable :)
>
> thanks,
>
> greg k-h
>
Regards
Burn Alting
^ permalink raw reply
* RE: EXT :Re: [RFC] Create an audit record of USB specific details
From: Boyce, Kevin P (AS) @ 2016-04-05 11:49 UTC (permalink / raw)
To: Wade Mealing, Bjørn Mork
Cc: Oliver Neukum, linux-kernel@vger.kernel.org, linux-usb,
linux-audit@redhat.com
In-Reply-To: <CALJHwhR5FQaa6v=ZPyLRZ8L+OrucXqEiwe6QE43HybM2keErYg@mail.gmail.com>
Wade,
Wouldn't this imply that every time the system is booted and the PCI bus for example is enumerated and all of the devices are created that all of those activities generate audit events?
That sounds less than desiriable. Does this imply that the audit subsystem should maintain a "baseline" of hardware that is always present on the system?
Couldn't you audit a directory under /proc/usb?
Correct me if I am wrong, but doesn't audititing of the syscall mknod create an event when devices are "added" to the system?
Kevin
-----Original Message-----
From: linux-audit-bounces@redhat.com [mailto:linux-audit-bounces@redhat.com] On Behalf Of Wade Mealing
Sent: Tuesday, April 05, 2016 4:40 AM
To: Bjørn Mork
Cc: Oliver Neukum; linux-kernel@vger.kernel.org; linux-usb; linux-audit@redhat.com
Subject: EXT :Re: [RFC] Create an audit record of USB specific details
I'm reframing my use case as follows to try and better explain the situation I am trying to track.
It might seem that I am duplicating existing functionality, rather I am trying to augment functionality that seems to be unavailable.Replication of existing functionality is not my intention.
Consider the following scenario. Currently we have device drivers that emit text via a printk request which is eventually picked up by syslog like implementation (not the audit subsystem).
The goal of these message is to let a system administrator see in the audit logs, that a device has been plugged in and the basic details about this. Having this only in userspace means that (and Greg alludes to this ) that this will be for human eyes only and not be machine usable in the kernels. Without it being in kernel, it can't be extended for manipulation by auditctl at some point in the future.
Specifically I am trying to create a well formed audit trail when devices are added or removed from the system by the userspace audit tools. The implementation at the moment does not do any filtering, but rather creates the raw audit events.
In some ways this is similar to a decorated class in say java. In this case the class is unaware it is being decorated yet we can monitor what is happening in that class without polluting the class code with messy log or trace information.
I don't see either kernel or user-space applications create add or remove events in the audit subsystem. I understand that some events are placed into uevents (To be intercepted by udevd), while this also exports the same information it is not in the audit subsystem in kernel.
> 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.
I agree it would be ideal to use existing userspace or kernelspace facilities for auditing and not duplicating efforts, it seems that the specific case I am trying to track isn't covered. Maybe I missed it be can you indicate where device add/remove audit (not log messages) are being generated/implemented in the kernel or userspace for the scenario I described?
Thanks,
Wade Mealing
--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply
* Re: [RFC] Create an audit record of USB specific details
From: Wade Mealing @ 2016-04-05 8:40 UTC (permalink / raw)
To: Bjørn Mork
Cc: Oliver Neukum, linux-audit-H+wXaHxf7aLQT0dZR+AlfA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, linux-usb
In-Reply-To: <87bn5pzuh1.fsf-lbf33ChDnrE/G1V5fR+Y7Q@public.gmane.org>
I'm reframing my use case as follows to try and better explain the
situation I am trying to track.
It might seem that I am duplicating existing functionality, rather I
am trying to augment functionality that seems to be
unavailable.Replication of existing functionality is not my intention.
Consider the following scenario. Currently we have device drivers
that emit text via a printk request which is eventually picked up by
syslog like implementation (not the audit subsystem).
The goal of these message is to let a system administrator see in the
audit logs, that a device has been plugged in and the basic details
about this. Having this only in userspace means that (and Greg
alludes to this ) that this will be for human eyes only and not be
machine usable in the kernels. Without it being in kernel, it can't
be extended for manipulation by auditctl at some point in the future.
Specifically I am trying to create a well formed audit trail when
devices are added or removed from the system by the userspace audit
tools. The implementation at the moment does not do any filtering,
but rather creates the raw audit events.
In some ways this is similar to a decorated class in say java. In
this case the class is unaware it is being decorated yet we can
monitor what is happening in that class without polluting the class
code with messy log or trace information.
I don't see either kernel or user-space applications create add or
remove events in the audit subsystem. I understand that some events
are placed into uevents (To be intercepted by udevd), while this also
exports the same information it is not in the audit subsystem in
kernel.
> 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.
I agree it would be ideal to use existing userspace or kernelspace
facilities for auditing and not duplicating efforts, it seems that the
specific case I am trying to track isn't covered. Maybe I missed it
be can you indicate where device add/remove audit (not log messages)
are being generated/implemented in the kernel or userspace for the
scenario I described?
Thanks,
Wade Mealing
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [RFC] Create an audit record of USB specific details
From: Greg KH @ 2016-04-05 3:39 UTC (permalink / raw)
To: Paul Moore; +Cc: linux-audit, wmealing, linux-kernel, linux-usb
In-Reply-To: <153e4582800.2832.85c95baa4474aabc7814e68940a78392@paul-moore.com>
On Mon, Apr 04, 2016 at 10:54:56PM -0400, Paul Moore wrote:
> On April 4, 2016 6:17:23 PM Greg KH <gregkh@linuxfoundation.org> wrote:
> > On Mon, Apr 04, 2016 at 05:37:58PM -0400, Paul Moore wrote:
> > > On Monday, April 04, 2016 05:56:26 AM Greg KH wrote:
> > > > On Mon, Apr 04, 2016 at 12:02:42AM -0400, wmealing wrote:
> > > > > From: Wade Mealing <wmealing@redhat.com>
> > > > >
> > > > > Gday,
> > > > >
> > > > > I'm looking to create an audit trail for when devices are added or removed
> > > > > from the system.
> > > >
> > > > Then please do it in userspace, as I suggested before, that way you
> > > > catch all types of devices, not just USB ones.
> > >
> > > Audit has some odd requirements placed on it by some of its users. I think
> > > most notable in this particular case is the need to take specific actions,
> > > including panicking the system, when audit records can't be sent to userspace
> > > and are "lost". Granted, it's an odd requirement, definitely not the
> > > norm/default configuration, but supporting weird stuff like this has allowed
> > > Linux to be used on some pretty interesting systems that wouldn't have been
> > > possible otherwise. Looking quickly at some of the kobject/uvent code, it
> > > doesn't appear that the uevent/netlink channel has this capability.
> >
> > Are you sure you can loose netlink messages? If you do, you know you
> > lost them, so isn't that good enough?
>
> Last I checked netlink didn't have a provision for panicking the system, so
> no :)
Userspace can panic the system if it detects this, so why not just do
that?
> > > It also just noticed that it looks like userspace can send fake uevent
> > > messages;
> >
> > That's how your machine boots properly :)
>
> Yes, it looks like that is how the initial devices are handled, right?
> Allowing something like that is probably okay for a variety of reasons, but
> I expect users would want to restrict access beyond this single trusted
> process. The good news is that I think you should be able to do that with a
> combination of DAC and MAC.
Again, please step back. What exactly are you trying to do here? What
is the requirement?
> > > I haven't looked at it closely enough yet, but that may be a concern
> > > for users which restrict/subdivide root using a LSM ... although it is
> > > possible that the LSM policy could help here. I'm thinking aloud a bit right
> > > now, but for SELinux the netlink controls aren't very granular and sysfs can
> > > be tricky so I can't say for certain about blocking fake events from userspace
> > > using LSMs/SELinux.
> >
> > uevents are not tied into LSMs from what I can tell, so I don't
> > understand wht you are talking about here, sorry.
>
> Perhaps I'm mistaken, but uevents are sent to userspace via netlink which
> does have LSM controls. There also appears to be a file I/O mechanism via
> sysfs which also has LSM controls.
And do any of them look at uevents through these mechanisms?
I doubt they care...
thanks,
greg k-h
^ permalink raw reply
* Re: [RFC] Create an audit record of USB specific details
From: Paul Moore @ 2016-04-05 2:54 UTC (permalink / raw)
To: Greg KH; +Cc: linux-audit, wmealing, linux-kernel, linux-usb
In-Reply-To: <20160404215041.GB26580@kroah.com>
On April 4, 2016 6:17:23 PM Greg KH <gregkh@linuxfoundation.org> wrote:
> On Mon, Apr 04, 2016 at 05:37:58PM -0400, Paul Moore wrote:
>> On Monday, April 04, 2016 05:56:26 AM Greg KH wrote:
>> > On Mon, Apr 04, 2016 at 12:02:42AM -0400, wmealing wrote:
>> > > From: Wade Mealing <wmealing@redhat.com>
>> > >
>> > > Gday,
>> > >
>> > > I'm looking to create an audit trail for when devices are added or removed
>> > > from the system.
>> >
>> > Then please do it in userspace, as I suggested before, that way you
>> > catch all types of devices, not just USB ones.
>>
>> Audit has some odd requirements placed on it by some of its users. I think
>> most notable in this particular case is the need to take specific actions,
>> including panicking the system, when audit records can't be sent to userspace
>> and are "lost". Granted, it's an odd requirement, definitely not the
>> norm/default configuration, but supporting weird stuff like this has allowed
>> Linux to be used on some pretty interesting systems that wouldn't have been
>> possible otherwise. Looking quickly at some of the kobject/uvent code, it
>> doesn't appear that the uevent/netlink channel has this capability.
>
> Are you sure you can loose netlink messages? If you do, you know you
> lost them, so isn't that good enough?
Last I checked netlink didn't have a provision for panicking the system, so
no :)
>> It also just noticed that it looks like userspace can send fake uevent
>> messages;
>
> That's how your machine boots properly :)
Yes, it looks like that is how the initial devices are handled, right?
Allowing something like that is probably okay for a variety of reasons, but
I expect users would want to restrict access beyond this single trusted
process. The good news is that I think you should be able to do that with
a combination of DAC and MAC.
>> I haven't looked at it closely enough yet, but that may be a concern
>> for users which restrict/subdivide root using a LSM ... although it is
>> possible that the LSM policy could help here. I'm thinking aloud a bit right
>> now, but for SELinux the netlink controls aren't very granular and sysfs can
>> be tricky so I can't say for certain about blocking fake events from userspace
>> using LSMs/SELinux.
>
> uevents are not tied into LSMs from what I can tell, so I don't
> understand wht you are talking about here, sorry.
Perhaps I'm mistaken, but uevents are sent to userspace via netlink which
does have LSM controls. There also appears to be a file I/O mechanism via
sysfs which also has LSM controls.
^ permalink raw reply
* Re: [RFC] Create an audit record of USB specific details
From: Greg KH @ 2016-04-05 2:47 UTC (permalink / raw)
To: Wade Mealing
Cc: Steve Grubb, linux-audit-H+wXaHxf7aLQT0dZR+AlfA, linux-usb,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <CALJHwhSaimur4w_WqjNOV6dawuDTvqQ5KGM52741Hq=DYMHaAQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Tue, Apr 05, 2016 at 11:54:07AM +1000, Wade Mealing wrote:
> That is a good question, maybe I've been lucky in the devices that I have
> been testing with. Most of them seem to be ascii, my assumption was that
> shouldn't be a problem. The same encoding function used by the path
> audit_log_d_path, definitely audits UTF8 named files:
>
> # ausearch -i -f /tmp/test/권성주.txt
Please look at the USB spec to see the encoding that USB strings are in.
They are in UTF-16LE, but we do some manipulation of them in the call to
usb_string() to make them semi-readable by the kernel.
But, as we aren't doing anything important with these, except printing
them out for people to lovingly gaze at, that's just fine. But if you
need to do policy decisions based on them, well, you better use the
"real" version of the string, otherwise you could run into major
problems.
But again, please step back, what are the requirements here that you are
doing this work for? If it's just for fun, wonderful, but please say so
when you post the patches so we don't take them seriously.
Well, I'm not taking them seriously now as obviously they will not work,
so I guess all is fine :)
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [RFC] Create an audit record of USB specific details
From: Greg KH @ 2016-04-05 2:43 UTC (permalink / raw)
To: Wade Mealing
Cc: Steve Grubb, linux-audit-H+wXaHxf7aLQT0dZR+AlfA, linux-usb,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <CALJHwhSaimur4w_WqjNOV6dawuDTvqQ5KGM52741Hq=DYMHaAQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
A: No.
Q: Should I include quotations after my reply?
http://daringfireball.net/2007/07/on_top
On Tue, Apr 05, 2016 at 11:54:07AM +1000, Wade Mealing wrote:
> That is a good question
What is?
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [RFC] Create an audit record of USB specific details
From: Wade Mealing @ 2016-04-05 1:54 UTC (permalink / raw)
To: Greg KH; +Cc: linux-kernel, linux-usb, linux-audit
In-Reply-To: <CALJHwhR-SA7K=fD=DUXE7EFq+4gWKPaY+B5z6jdCj7180wg_vg@mail.gmail.com>
That is a good question, maybe I've been lucky in the devices that I have
been testing with. Most of them seem to be ascii, my assumption was that
shouldn't be a problem. The same encoding function used by the path
audit_log_d_path, definitely audits UTF8 named files:
# ausearch -i -f /tmp/test/권성주.txt
type=PATH msg=audit(04/04/16 21:05:00.521:1638) : item=0 name=/tmp/권성주.txt
inode=627534 dev=fd:00 mode=file,664 ouid=wmealing ogid=wmealing rdev=00:00
obj=unconfined_u:object_r:user_tmp_t:s0 objtype=NORMAL
# ausearch -f /tmp/test/권성주.txt
type=PATH msg=audit(1459818300.521:1638): item=0
name=2F746D702FEAB68CEC84B1ECA3BC2E747874 inode=627534 dev=fd:00
mode=0100664 ouid=1000 ogid=1000 rdev=00:00
obj=unconfined_u:object_r:user_tmp_t:s0 objtype=NORMAL
Thanks,
Wade Mealing.
On Tue, Apr 5, 2016 at 11:51 AM, Wade Mealing <wmealing@redhat.com> wrote:
> That is a good question, maybe I've been lucky in the devices that I have
> been testing with. Most of them seem to be ascii, my assumption was that
> shouldn't be a problem. The same encoding function used by the path
> audit_log_d_path, definitely audits UTF8 named files:
>
> # ausearch -i -f /tmp/test/권성주.txt
>
> type=PATH msg=audit(04/04/16 21:05:00.521:1638) : item=0 name=/tmp/권성주.txt
> inode=627534 dev=fd:00 mode=file,664 ouid=wmealing ogid=wmealing rdev=00:00
> obj=unconfined_u:object_r:user_tmp_t:s0 objtype=NORMAL
>
> # ausearch -f /tmp/test/권성주.txt
>
> type=PATH msg=audit(1459818300.521:1638): item=0
> name=2F746D702FEAB68CEC84B1ECA3BC2E747874 inode=627534 dev=fd:00
> mode=0100664 ouid=1000 ogid=1000 rdev=00:00
> obj=unconfined_u:object_r:user_tmp_t:s0 objtype=NORMAL
>
> Thanks,
>
> Wade Mealing.
>
> On Tue, Apr 5, 2016 at 7:54 AM, Greg KH <greg@kroah.com> wrote:
>>
>> On Mon, Apr 04, 2016 at 05:37:01PM -0400, Steve Grubb wrote:
>> > On Monday, April 04, 2016 12:02:42 AM 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.
>> > >
>> > > 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.
>> > >
>> > > Here is an example of picking out the AUDIT_DEVICE record type for
>> > > example.
>> > >
>> > > > # ausearch -l -i -ts today -m AUDIT_DEVICE
>> > > > ----
>> > > > type=AUDIT_DEVICE msg=audit(31/03/16 16:37:15.642:2) : action=add
>> > > > manufacturer=Linux 4.4.0-ktest ehci_hcd product=EHCI Host Controller
>> > > > serial=0000:00:06.7 major=189 minor=0 bus="usb"
>> >
>> > About this event's format...we can't have any spaces in the value side
>> > of the
>> > name=value fields unless its encoded as an untrusted string. You can
>> > replace
>> > spaces with an underscore or dash for readability. So, manufacturer and
>> > product would need this treatment.
>>
>> What is the character encoding that audit messages can accept? Does it
>> match up with the character encoding that USB strings are in?
>>
>> thanks,
>>
>> greg k-h
>
>
--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply
* Re: [RFC] Create an audit record of USB specific details
From: Wade Mealing @ 2016-04-05 1:51 UTC (permalink / raw)
To: Greg KH; +Cc: linux-kernel, linux-usb, linux-audit
In-Reply-To: <20160404215422.GA26969@kroah.com>
[-- Attachment #1.1: Type: text/plain, Size: 2801 bytes --]
That is a good question, maybe I've been lucky in the devices that I have
been testing with. Most of them seem to be ascii, my assumption was that
shouldn't be a problem. The same encoding function used by the path
audit_log_d_path, definitely audits UTF8 named files:
# ausearch -i -f /tmp/test/권성주.txt
type=PATH msg=audit(04/04/16 21:05:00.521:1638) : item=0 name=/tmp/권성주.txt
inode=627534 dev=fd:00 mode=file,664 ouid=wmealing ogid=wmealing rdev=00:00
obj=unconfined_u:object_r:user_tmp_t:s0 objtype=NORMAL
# ausearch -f /tmp/test/권성주.txt
type=PATH msg=audit(1459818300.521:1638): item=0
name=2F746D702FEAB68CEC84B1ECA3BC2E747874 inode=627534 dev=fd:00
mode=0100664 ouid=1000 ogid=1000 rdev=00:00
obj=unconfined_u:object_r:user_tmp_t:s0 objtype=NORMAL
Thanks,
Wade Mealing.
On Tue, Apr 5, 2016 at 7:54 AM, Greg KH <greg@kroah.com> wrote:
> On Mon, Apr 04, 2016 at 05:37:01PM -0400, Steve Grubb wrote:
> > On Monday, April 04, 2016 12:02:42 AM 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.
> > >
> > > 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.
> > >
> > > Here is an example of picking out the AUDIT_DEVICE record type for
> example.
> > >
> > > > # ausearch -l -i -ts today -m AUDIT_DEVICE
> > > > ----
> > > > type=AUDIT_DEVICE msg=audit(31/03/16 16:37:15.642:2) : action=add
> > > > manufacturer=Linux 4.4.0-ktest ehci_hcd product=EHCI Host Controller
> > > > serial=0000:00:06.7 major=189 minor=0 bus="usb"
> >
> > About this event's format...we can't have any spaces in the value side
> of the
> > name=value fields unless its encoded as an untrusted string. You can
> replace
> > spaces with an underscore or dash for readability. So, manufacturer and
> > product would need this treatment.
>
> What is the character encoding that audit messages can accept? Does it
> match up with the character encoding that USB strings are in?
>
> thanks,
>
> greg k-h
>
[-- Attachment #1.2: Type: text/html, Size: 3585 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: [RFC] Create an audit record of USB specific details
From: Burn Alting @ 2016-04-04 22:10 UTC (permalink / raw)
To: Steve Grubb; +Cc: linux-audit, linux-usb, linux-kernel
In-Reply-To: <4430946.BXbQgWNMDe@x2>
On Mon, 2016-04-04 at 17:37 -0400, Steve Grubb wrote:
> On Monday, April 04, 2016 12:02:42 AM 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.
> >
> > 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.
> >
> > Here is an example of picking out the AUDIT_DEVICE record type for example.
> >
> > > # ausearch -l -i -ts today -m AUDIT_DEVICE
> > > ----
> > > type=AUDIT_DEVICE msg=audit(31/03/16 16:37:15.642:2) : action=add
> > > manufacturer=Linux 4.4.0-ktest ehci_hcd product=EHCI Host Controller
> > > serial=0000:00:06.7 major=189 minor=0 bus="usb"
>
> About this event's format...we can't have any spaces in the value side of the
> name=value fields unless its encoded as an untrusted string. You can replace
> spaces with an underscore or dash for readability. So, manufacturer and
> product would need this treatment.
>
> -Steve
I think you'll find the original event has properly encoded strings ...
note the '-i' on the ausearch.
>
> > Admittedly this is only the USB device type at the moment, but I'd like to
> > break this out into other bus types at some time in the future, gotta start
> > somewhere.
^ permalink raw reply
* Re: [RFC] Create an audit record of USB specific details
From: Greg KH @ 2016-04-04 21:54 UTC (permalink / raw)
To: Steve Grubb; +Cc: linux-audit, wmealing, linux-usb, linux-kernel
In-Reply-To: <4430946.BXbQgWNMDe@x2>
On Mon, Apr 04, 2016 at 05:37:01PM -0400, Steve Grubb wrote:
> On Monday, April 04, 2016 12:02:42 AM 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.
> >
> > 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.
> >
> > Here is an example of picking out the AUDIT_DEVICE record type for example.
> >
> > > # ausearch -l -i -ts today -m AUDIT_DEVICE
> > > ----
> > > type=AUDIT_DEVICE msg=audit(31/03/16 16:37:15.642:2) : action=add
> > > manufacturer=Linux 4.4.0-ktest ehci_hcd product=EHCI Host Controller
> > > serial=0000:00:06.7 major=189 minor=0 bus="usb"
>
> About this event's format...we can't have any spaces in the value side of the
> name=value fields unless its encoded as an untrusted string. You can replace
> spaces with an underscore or dash for readability. So, manufacturer and
> product would need this treatment.
What is the character encoding that audit messages can accept? Does it
match up with the character encoding that USB strings are in?
thanks,
greg k-h
^ permalink raw reply
* Re: [RFC] Create an audit record of USB specific details
From: Greg KH @ 2016-04-04 21:53 UTC (permalink / raw)
To: Steve Grubb
Cc: linux-audit-H+wXaHxf7aLQT0dZR+AlfA, wmealing,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20160404214843.GA26580-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org>
On Mon, Apr 04, 2016 at 02:48:43PM -0700, Greg KH wrote:
> On Mon, Apr 04, 2016 at 05:33:10PM -0400, Steve Grubb wrote:
> > On Monday, April 04, 2016 05:56:26 AM Greg KH wrote:
> > > On Mon, Apr 04, 2016 at 12:02:42AM -0400, wmealing wrote:
> > > > From: Wade Mealing <wmealing-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> > > >
> > > > Gday,
> > > >
> > > > I'm looking to create an audit trail for when devices are added or removed
> > > > from the system.
> > >
> > > Then please do it in userspace, as I suggested before, that way you
> > > catch all types of devices, not just USB ones.
> > >
> > > Also I don't think you realize that USB interfaces are what are bound to
> > > drivers, not USB devices, so that is going to mess with any attempted
> > > audit trails here. How are you going to distinguish between the 5
> > > different devices that just got plugged in that all have 0000/0000 as
> > > vid/pid for them because they are "cheap" devices from China, yet do
> > > totally different things because they are different _types_ of devices?
> >
> > This sounds like vid/pid should be captured in the event.
>
> The code did that, the point is, vid/pid means nothing in the real
> world. So why are you going to audit anything based on it? :)
Oh wait, it's worse, it is logging strings, which are even more
unreliable than vid/pid values. It's pretty obvious this has not been
tested on any large batch of real-world devices, or thought through as
to why any of this is even needed at all.
So why is this being added? Who needs/wants this? What are their
requirements here? From what I recall, the author is just messing
around with the USB subsystem and audit as something fun to do, which is
great, but don't expect it to be mergable :)
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [RFC] Create an audit record of USB specific details
From: Greg KH @ 2016-04-04 21:50 UTC (permalink / raw)
To: Paul Moore; +Cc: linux-audit, wmealing, linux-kernel, linux-usb
In-Reply-To: <1712342.QWWAT5XPGs@sifl>
On Mon, Apr 04, 2016 at 05:37:58PM -0400, Paul Moore wrote:
> On Monday, April 04, 2016 05:56:26 AM Greg KH wrote:
> > On Mon, Apr 04, 2016 at 12:02:42AM -0400, wmealing wrote:
> > > From: Wade Mealing <wmealing@redhat.com>
> > >
> > > Gday,
> > >
> > > I'm looking to create an audit trail for when devices are added or removed
> > > from the system.
> >
> > Then please do it in userspace, as I suggested before, that way you
> > catch all types of devices, not just USB ones.
>
> Audit has some odd requirements placed on it by some of its users. I think
> most notable in this particular case is the need to take specific actions,
> including panicking the system, when audit records can't be sent to userspace
> and are "lost". Granted, it's an odd requirement, definitely not the
> norm/default configuration, but supporting weird stuff like this has allowed
> Linux to be used on some pretty interesting systems that wouldn't have been
> possible otherwise. Looking quickly at some of the kobject/uvent code, it
> doesn't appear that the uevent/netlink channel has this capability.
Are you sure you can loose netlink messages? If you do, you know you
lost them, so isn't that good enough?
> It also just noticed that it looks like userspace can send fake uevent
> messages;
That's how your machine boots properly :)
> I haven't looked at it closely enough yet, but that may be a concern
> for users which restrict/subdivide root using a LSM ... although it is
> possible that the LSM policy could help here. I'm thinking aloud a bit right
> now, but for SELinux the netlink controls aren't very granular and sysfs can
> be tricky so I can't say for certain about blocking fake events from userspace
> using LSMs/SELinux.
uevents are not tied into LSMs from what I can tell, so I don't
understand wht you are talking about here, sorry.
thanks,
greg k-h
^ permalink raw reply
* Re: [RFC] Create an audit record of USB specific details
From: Greg KH @ 2016-04-04 21:48 UTC (permalink / raw)
To: Steve Grubb; +Cc: linux-audit, wmealing, linux-kernel, linux-usb
In-Reply-To: <8028201.ZHuhRfiKWv@x2>
On Mon, Apr 04, 2016 at 05:33:10PM -0400, Steve Grubb wrote:
> On Monday, April 04, 2016 05:56:26 AM Greg KH wrote:
> > On Mon, Apr 04, 2016 at 12:02:42AM -0400, wmealing wrote:
> > > From: Wade Mealing <wmealing@redhat.com>
> > >
> > > Gday,
> > >
> > > I'm looking to create an audit trail for when devices are added or removed
> > > from the system.
> >
> > Then please do it in userspace, as I suggested before, that way you
> > catch all types of devices, not just USB ones.
> >
> > Also I don't think you realize that USB interfaces are what are bound to
> > drivers, not USB devices, so that is going to mess with any attempted
> > audit trails here. How are you going to distinguish between the 5
> > different devices that just got plugged in that all have 0000/0000 as
> > vid/pid for them because they are "cheap" devices from China, yet do
> > totally different things because they are different _types_ of devices?
>
> This sounds like vid/pid should be captured in the event.
The code did that, the point is, vid/pid means nothing in the real
world. So why are you going to audit anything based on it? :)
> > Again, do this in userspace please, that is where it belongs.
>
> There is one issue that may need some clarification. The audit system has to do
> everything possible to make sure that an event is captured and logged. Does
> the uevent netlink protocol ever drop events because the user space queue is
> full? If the uevent interface drops events, then its not audit quality in
> terms of doing everything possible to prevent the loss of a record. If this
> were to happen, how would user space find out when a uevent gets dropped? I may
> have to panic the machine if that happens depending on the configured policy.
> So, we need to know when it happens. If on the otherhand it doesn't ever drop
> events, then it might be usable.
I have never seen it drop events, have you? It's been pretty reliable
for the past 10+ years :)
thanks,
greg k-h
^ permalink raw reply
* Re: [RFC] Create an audit record of USB specific details
From: Paul Moore @ 2016-04-04 21:37 UTC (permalink / raw)
To: linux-audit, Greg KH, wmealing; +Cc: linux-kernel, linux-usb
In-Reply-To: <20160404125626.GB6197@kroah.com>
On Monday, April 04, 2016 05:56:26 AM Greg KH wrote:
> On Mon, Apr 04, 2016 at 12:02:42AM -0400, wmealing wrote:
> > From: Wade Mealing <wmealing@redhat.com>
> >
> > Gday,
> >
> > I'm looking to create an audit trail for when devices are added or removed
> > from the system.
>
> Then please do it in userspace, as I suggested before, that way you
> catch all types of devices, not just USB ones.
Audit has some odd requirements placed on it by some of its users. I think
most notable in this particular case is the need to take specific actions,
including panicking the system, when audit records can't be sent to userspace
and are "lost". Granted, it's an odd requirement, definitely not the
norm/default configuration, but supporting weird stuff like this has allowed
Linux to be used on some pretty interesting systems that wouldn't have been
possible otherwise. Looking quickly at some of the kobject/uvent code, it
doesn't appear that the uevent/netlink channel has this capability.
It also just noticed that it looks like userspace can send fake uevent
messages; I haven't looked at it closely enough yet, but that may be a concern
for users which restrict/subdivide root using a LSM ... although it is
possible that the LSM policy could help here. I'm thinking aloud a bit right
now, but for SELinux the netlink controls aren't very granular and sysfs can
be tricky so I can't say for certain about blocking fake events from userspace
using LSMs/SELinux.
--
paul moore
www.paul-moore.com
^ permalink raw reply
* Re: [RFC] Create an audit record of USB specific details
From: Steve Grubb @ 2016-04-04 21:37 UTC (permalink / raw)
To: linux-audit; +Cc: wmealing, linux-usb, linux-kernel
In-Reply-To: <1459742562-22803-1-git-send-email-wmail@redhat.com>
On Monday, April 04, 2016 12:02:42 AM 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.
>
> 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.
>
> Here is an example of picking out the AUDIT_DEVICE record type for example.
>
> > # ausearch -l -i -ts today -m AUDIT_DEVICE
> > ----
> > type=AUDIT_DEVICE msg=audit(31/03/16 16:37:15.642:2) : action=add
> > manufacturer=Linux 4.4.0-ktest ehci_hcd product=EHCI Host Controller
> > serial=0000:00:06.7 major=189 minor=0 bus="usb"
About this event's format...we can't have any spaces in the value side of the
name=value fields unless its encoded as an untrusted string. You can replace
spaces with an underscore or dash for readability. So, manufacturer and
product would need this treatment.
-Steve
> Admittedly this is only the USB device type at the moment, but I'd like to
> break this out into other bus types at some time in the future, gotta start
> somewhere.
^ permalink raw reply
* Re: [RFC] Create an audit record of USB specific details
From: Steve Grubb @ 2016-04-04 21:33 UTC (permalink / raw)
To: linux-audit; +Cc: Greg KH, wmealing, linux-kernel, linux-usb
In-Reply-To: <20160404125626.GB6197@kroah.com>
On Monday, April 04, 2016 05:56:26 AM Greg KH wrote:
> On Mon, Apr 04, 2016 at 12:02:42AM -0400, wmealing wrote:
> > From: Wade Mealing <wmealing@redhat.com>
> >
> > Gday,
> >
> > I'm looking to create an audit trail for when devices are added or removed
> > from the system.
>
> Then please do it in userspace, as I suggested before, that way you
> catch all types of devices, not just USB ones.
>
> Also I don't think you realize that USB interfaces are what are bound to
> drivers, not USB devices, so that is going to mess with any attempted
> audit trails here. How are you going to distinguish between the 5
> different devices that just got plugged in that all have 0000/0000 as
> vid/pid for them because they are "cheap" devices from China, yet do
> totally different things because they are different _types_ of devices?
This sounds like vid/pid should be captured in the event.
> Again, do this in userspace please, that is where it belongs.
There is one issue that may need some clarification. The audit system has to do
everything possible to make sure that an event is captured and logged. Does
the uevent netlink protocol ever drop events because the user space queue is
full? If the uevent interface drops events, then its not audit quality in
terms of doing everything possible to prevent the loss of a record. If this
were to happen, how would user space find out when a uevent gets dropped? I may
have to panic the machine if that happens depending on the configured policy.
So, we need to know when it happens. If on the otherhand it doesn't ever drop
events, then it might be usable.
-Steve
^ permalink raw reply
* Re: auditd reports port number '0' for connect() system call
From: Kangkook Jee @ 2016-04-04 18:32 UTC (permalink / raw)
To: Steve Grubb; +Cc: linux-audit
In-Reply-To: <18729284.EaRmKyajcD@x2>
Thanks a lot Steve! I really helps.
Regards, Kangkook
> On Apr 1, 2016, at 8:13 AM, Steve Grubb <sgrubb@redhat.com> wrote:
>
> On Thursday, March 31, 2016 06:11:26 PM Kangkook Jee wrote:
>> Here an event directly from auditd for connect() system call (syscall=42)
>> with port number 0. Do you think connect() system call still can be called
>> with port number 0?
>
>
> Hello,
>
> I got the full events. Below is the explanation...
>
> type=SYSCALL msg=audit(03/29/2016 21:33:27.178:35720094) : arch=x86_64
> syscall=socket success=yes exit=44 a0=inet a1=SOCK_DGRAM a2=ip a3=0x0 items=0
> ppid=2779 pid=31713 auid=unset uid=unknown(8271) gid=unknown(5001)
> euid=unknown(8271) suid=unknown(8271) fsuid=unknown(8271) egid=unknown(5001)
> sgid=unknown(5001) fsgid=unknown(5001) tty=(none) ses=unset comm=DNS Res~er
> #465 exe=/usr/lib/firefox/firefox key=(null)
>
> So, here ^^^ we are creating a DGRAM socket. This is important because they
> follow slightly different rules than tcp.
>
>
> type=SOCKADDR msg=audit(03/29/2016 21:33:27.178:35720095) : saddr=inet
> host:54.68.122.100 serv:0
> type=SYSCALL msg=audit(03/29/2016 21:33:27.178:35720095) : arch=x86_64
> syscall=connect success=yes exit=0 a0=0x2c a1=0x7f1fbe8f81f0 a2=0x10 a3=0x0
> items=0 ppid=2779 pid=31713 auid=unset uid=unknown(8271) gid=unknown(5001)
> euid=unknown(8271) suid=unknown(8271) fsuid=unknown(8271) egid=unknown(5001)
> sgid=unknown(5001) fsgid=unknown(5001) tty=(none) ses=unset comm=DNS Res~er
> #465 exe=/usr/lib/firefox/firefox key=(null)
>
>
> http://man7.org/linux/man-pages/man2/connect.2.html
> If the socket sockfd is of type SOCK_DGRAM, then addr is the address to which
> datagrams are sent by default, and the only address from which datagrams are
> received.
>
> So, this is just setting up a connectionless socket to a specific server.
> Judging by the thread name, this is for DNS resolution for Firefox. So, I
> would say that without a doubt, this is normal system operation.
>
> -Steve
>
>
>> type=SYSCALL msg=audit(1459301607.178:35720095): arch=c000003e syscall=42
>> success=yes exit=0 a0=2c a1=7f1fbe8f81f0 a2=10 a3=0 items=0 ppid=2779
>> pid=31713 auid=4294967295 uid=8271 gid=5001 euid=8271 suid=8271 fsuid=8271
>> egid=5001 sgid=500# type=SOCKADDR msg=audit(1459301607.178:35720095):
>> saddr=0200000036447A640000000000000000
>>
>> If it is bind() it makes but I’m not sure we can still do this with
>> connect().
>>
>> Thanks!
>>
>> /Kangkook
>
--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox