* [RFC] Create an audit record of USB specific details
@ 2016-04-04 4:02 wmealing
[not found] ` <1459742562-22803-1-git-send-email-wmail-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
` (2 more replies)
0 siblings, 3 replies; 52+ messages in thread
From: wmealing @ 2016-04-04 4:02 UTC (permalink / raw)
To: linux-audit; +Cc: linux-kernel, linux-usb, Wade Mealing
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.
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"
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.
Thanks,
Wade Mealing
---
include/uapi/linux/audit.h | 1 +
init/Kconfig | 10 ++++++
kernel/Makefile | 1 +
kernel/audit_device.c | 90 ++++++++++++++++++++++++++++++++++++++++++++++
4 files changed, 102 insertions(+)
create mode 100644 kernel/audit_device.c
diff --git a/include/uapi/linux/audit.h b/include/uapi/linux/audit.h
index 843540c..344c97b 100644
--- a/include/uapi/linux/audit.h
+++ b/include/uapi/linux/audit.h
@@ -110,6 +110,7 @@
#define AUDIT_SECCOMP 1326 /* Secure Computing event */
#define AUDIT_PROCTITLE 1327 /* Proctitle emit event */
#define AUDIT_FEATURE_CHANGE 1328 /* audit log listing feature changes */
+#define AUDIT_DEVICE_CHANGE 1330 /* Device added/removed to the system */
#define AUDIT_AVC 1400 /* SE Linux avc denial or grant */
#define AUDIT_SELINUX_ERR 1401 /* Internal SE Linux Errors */
diff --git a/init/Kconfig b/init/Kconfig
index 2232080..e171f74 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -309,6 +309,16 @@ config AUDITSYSCALL
def_bool y
depends on AUDIT && HAVE_ARCH_AUDITSYSCALL
+config DEVICE_AUDIT
+ bool "Create audit records for devices added to the systems"
+ depends on AUDIT && USB
+ default y
+ help
+ Generate audit events in the system for USB devices that
+ are added or removed from the system from boot time onwards.
+ Records the manufacturer, product serial number, device major
+ and minor number and bus which the device was added to.
+
config AUDIT_WATCH
def_bool y
depends on AUDITSYSCALL
diff --git a/kernel/Makefile b/kernel/Makefile
index 53abf00..909c869 100644
--- a/kernel/Makefile
+++ b/kernel/Makefile
@@ -68,6 +68,7 @@ obj-$(CONFIG_AUDIT) += audit.o auditfilter.o
obj-$(CONFIG_AUDITSYSCALL) += auditsc.o
obj-$(CONFIG_AUDIT_WATCH) += audit_watch.o audit_fsnotify.o
obj-$(CONFIG_AUDIT_TREE) += audit_tree.o
+obj-$(CONFIG_DEVICE_AUDIT) += audit_device.o
obj-$(CONFIG_GCOV_KERNEL) += gcov/
obj-$(CONFIG_KPROBES) += kprobes.o
obj-$(CONFIG_KGDB) += debug/
diff --git a/kernel/audit_device.c b/kernel/audit_device.c
new file mode 100644
index 0000000..8dfdf04
--- /dev/null
+++ b/kernel/audit_device.c
@@ -0,0 +1,90 @@
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/usb.h>
+#include <linux/usb/hcd.h>
+#include <linux/slab.h>
+#include <linux/notifier.h>
+#include <linux/mutex.h>
+#include <linux/device.h>
+#include <linux/usb.h>
+#include <linux/audit.h>
+#include <linux/kdev_t.h>
+
+static void log_string(struct audit_buffer *ab, char *key, char *val)
+{
+ if (val) {
+ audit_log_format(ab, " %s=", key);
+ audit_log_untrustedstring(ab, val);
+ }
+ else {
+ audit_log_format(ab, " %s=%s", key, "?");
+ }
+
+}
+
+static void log_major_minor(struct audit_buffer *ab, struct device *dev)
+{
+ if (dev && dev->devt) {
+ audit_log_format(ab, " major=%d", MAJOR(dev->devt));
+ audit_log_format(ab, " minor=%d", MINOR(dev->devt));
+ }
+}
+
+/* Blocking call when device has reference and will keep reference until
+ * all notifiers are done, no usb_dev_get/ usb_dev_put required.
+ */
+static int audit_notify(struct notifier_block *self,
+ unsigned long action, void *d)
+{
+ struct usb_device *usbdev = (struct usb_device *)d;
+ char *op;
+ struct audit_buffer *ab;
+
+ switch (action) {
+ case USB_DEVICE_ADD:
+ op = "add";
+ break;
+ case USB_DEVICE_REMOVE:
+ op = "remove";
+ break;
+ default: /* ignore any other USB events */
+ return NOTIFY_DONE;
+ }
+
+ ab = audit_log_start(NULL, GFP_KERNEL, AUDIT_DEVICE_CHANGE);
+
+ if (ab) {
+ audit_log_format(ab, "action=%s", op);
+ log_string(ab, "manufacturer", usbdev->manufacturer);
+ log_string(ab, "product", usbdev->product);
+ log_string(ab, "serial", usbdev->serial);
+ log_major_minor(ab, &usbdev->dev);
+ log_string(ab, "bus", "usb");
+ audit_log_end(ab);
+ }
+
+ return NOTIFY_DONE;
+}
+
+static struct notifier_block audit_nb = {
+ .notifier_call = audit_notify,
+ .priority = INT_MIN
+};
+
+static int __init audit_device_init(void)
+{
+ pr_info("Registering usb audit notification callback\n");
+ usb_register_notify(&audit_nb);
+ return 0;
+}
+
+static void __exit audit_device_exit(void)
+{
+ pr_info("Unregistering usb audit notification callback\n");
+ usb_unregister_notify(&audit_nb);
+}
+
+module_init(audit_device_init);
+module_exit(audit_device_exit);
+
+MODULE_LICENSE("GPL");
--
1.8.3.1
^ permalink raw reply related [flat|nested] 52+ messages in thread[parent not found: <1459742562-22803-1-git-send-email-wmail-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>]
* Re: [RFC] Create an audit record of USB specific details
2016-04-04 4:02 [RFC] Create an audit record of USB specific details wmealing
@ 2016-04-04 6:48 ` Oliver Neukum
2016-04-04 12:56 ` Greg KH
2016-04-04 21:37 ` Steve Grubb
2 siblings, 0 replies; 52+ messages in thread
From: Oliver Neukum @ 2016-04-04 6:48 UTC (permalink / raw)
To: wmealing
Cc: linux-audit-H+wXaHxf7aLQT0dZR+AlfA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA
On Mon, 2016-04-04 at 00:02 -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.
>
> 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.
> 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.
Regards
Oliver
--
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 [flat|nested] 52+ messages in thread
* Re: [RFC] Create an audit record of USB specific details
@ 2016-04-04 6:48 ` Oliver Neukum
0 siblings, 0 replies; 52+ messages in thread
From: Oliver Neukum @ 2016-04-04 6:48 UTC (permalink / raw)
To: wmealing; +Cc: linux-audit, linux-kernel, linux-usb
On Mon, 2016-04-04 at 00:02 -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.
>
> 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.
> 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.
Regards
Oliver
^ permalink raw reply [flat|nested] 52+ messages in thread
[parent not found: <1459752519.24025.5.camel-IBi9RG/b67k@public.gmane.org>]
* Re: [RFC] Create an audit record of USB specific details
2016-04-04 6:48 ` Oliver Neukum
@ 2016-04-04 7:47 ` Bjørn Mork
-1 siblings, 0 replies; 52+ messages in thread
From: Bjørn Mork @ 2016-04-04 7:47 UTC (permalink / raw)
To: Oliver Neukum
Cc: wmealing, linux-audit-H+wXaHxf7aLQT0dZR+AlfA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA
Oliver Neukum <oneukum-IBi9RG/b67k@public.gmane.org> 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
--
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 [flat|nested] 52+ messages in thread
* Re: [RFC] Create an audit record of USB specific details
@ 2016-04-04 7:47 ` Bjørn Mork
0 siblings, 0 replies; 52+ messages in thread
From: Bjørn Mork @ 2016-04-04 7:47 UTC (permalink / raw)
To: Oliver Neukum; +Cc: wmealing, linux-audit, linux-kernel, linux-usb
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
^ permalink raw reply [flat|nested] 52+ messages in thread
[parent not found: <87bn5pzuh1.fsf-lbf33ChDnrE/G1V5fR+Y7Q@public.gmane.org>]
* Re: [RFC] Create an audit record of USB specific details
2016-04-04 7:47 ` Bjørn Mork
@ 2016-04-05 8:40 ` Wade Mealing
-1 siblings, 0 replies; 52+ messages in thread
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
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 [flat|nested] 52+ messages in thread
* Re: [RFC] Create an audit record of USB specific details
@ 2016-04-05 8:40 ` Wade Mealing
0 siblings, 0 replies; 52+ messages in thread
From: Wade Mealing @ 2016-04-05 8:40 UTC (permalink / raw)
To: Bjørn Mork; +Cc: Oliver Neukum, linux-audit, linux-kernel, linux-usb
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
^ permalink raw reply [flat|nested] 52+ messages in thread
* RE: EXT :Re: [RFC] Create an audit record of USB specific details
2016-04-05 8:40 ` Wade Mealing
(?)
@ 2016-04-05 11:49 ` Boyce, Kevin P (AS)
2016-04-05 13:46 ` Greg KH
-1 siblings, 1 reply; 52+ messages in thread
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
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 [flat|nested] 52+ messages in thread
* Re: EXT :Re: [RFC] Create an audit record of USB specific details
2016-04-05 11:49 ` EXT :Re: " Boyce, Kevin P (AS)
@ 2016-04-05 13:46 ` Greg KH
2016-04-05 13:52 ` Boyce, Kevin P (AS)
0 siblings, 1 reply; 52+ messages in thread
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
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 [flat|nested] 52+ messages in thread
* RE: EXT :Re: [RFC] Create an audit record of USB specific details
2016-04-05 13:46 ` Greg KH
@ 2016-04-05 13:52 ` Boyce, Kevin P (AS)
[not found] ` <6bdd24ee68e64e4e91fa160940d357ed-cZmdoFAsBjDgAiKnVY1dJgQSgKfZeEaX@public.gmane.org>
0 siblings, 1 reply; 52+ messages in thread
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
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 [flat|nested] 52+ messages in thread
* Re: [RFC] Create an audit record of USB specific details
2016-04-05 8:40 ` Wade Mealing
(?)
(?)
@ 2016-04-05 14:40 ` Alan Stern
2016-04-05 22:17 ` Wade Mealing
-1 siblings, 1 reply; 52+ messages in thread
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
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 [flat|nested] 52+ messages in thread
* Re: [RFC] Create an audit record of USB specific details
2016-04-05 14:40 ` Alan Stern
@ 2016-04-05 22:17 ` Wade Mealing
0 siblings, 0 replies; 52+ messages in thread
From: Wade Mealing @ 2016-04-05 22:17 UTC (permalink / raw)
To: Alan Stern
Cc: Bjørn Mork, Oliver Neukum, linux-audit, linux-kernel,
linux-usb
O
>
> 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
I agree with you on this. The device_add and device_del functions
use notification chains
similar to how the USB subsystem can notify subscribers that new
devices have been added.
This was my initial implementation, USB already uses notification
chains for its device add/remove.
Thanks,
Wade Mealing.
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [RFC] Create an audit record of USB specific details
2016-04-05 8:40 ` Wade Mealing
` (2 preceding siblings ...)
(?)
@ 2016-04-05 17:02 ` Oliver Neukum
[not found] ` <1459875768.2892.1.camel-IBi9RG/b67k@public.gmane.org>
-1 siblings, 1 reply; 52+ messages in thread
From: Oliver Neukum @ 2016-04-05 17:02 UTC (permalink / raw)
To: Wade Mealing; +Cc: bjorn, linux-audit, linux-kernel, linux-usb
On Tue, 2016-04-05 at 18:40 +1000, Wade Mealing wrote:
> 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).
We also have UEVENTs. The crucial question is why udevd feeding
back events to the audit subsystem is inferior to the kernel
itself generating audit events.
Regards
Oliver
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [RFC] Create an audit record of USB specific details
2016-04-04 4:02 [RFC] Create an audit record of USB specific details wmealing
[not found] ` <1459742562-22803-1-git-send-email-wmail-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
@ 2016-04-04 12:56 ` Greg KH
2016-04-04 21:33 ` Steve Grubb
2016-04-04 21:37 ` Paul Moore
2016-04-04 21:37 ` Steve Grubb
2 siblings, 2 replies; 52+ messages in thread
From: Greg KH @ 2016-04-04 12:56 UTC (permalink / raw)
To: wmealing; +Cc: linux-audit, linux-kernel, linux-usb
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?
Again, do this in userspace please, that is where it belongs.
greg k-h
^ permalink raw reply [flat|nested] 52+ messages in thread* Re: [RFC] Create an audit record of USB specific details
2016-04-04 12:56 ` Greg KH
@ 2016-04-04 21:33 ` Steve Grubb
2016-04-04 21:48 ` Greg KH
2016-04-04 21:37 ` Paul Moore
1 sibling, 1 reply; 52+ messages in thread
From: Steve Grubb @ 2016-04-04 21:33 UTC (permalink / raw)
To: linux-audit; +Cc: Greg KH, wmealing, linux-kernel, linux-usb
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 [flat|nested] 52+ messages in thread
* Re: [RFC] Create an audit record of USB specific details
2016-04-04 21:33 ` Steve Grubb
@ 2016-04-04 21:48 ` Greg KH
[not found] ` <20160404214843.GA26580-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org>
0 siblings, 1 reply; 52+ messages in thread
From: Greg KH @ 2016-04-04 21:48 UTC (permalink / raw)
To: Steve Grubb; +Cc: linux-audit, wmealing, linux-kernel, linux-usb
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 [flat|nested] 52+ messages in thread
* Re: [RFC] Create an audit record of USB specific details
2016-04-04 12:56 ` Greg KH
2016-04-04 21:33 ` Steve Grubb
@ 2016-04-04 21:37 ` Paul Moore
2016-04-04 21:50 ` Greg KH
1 sibling, 1 reply; 52+ messages in thread
From: Paul Moore @ 2016-04-04 21:37 UTC (permalink / raw)
To: linux-audit, Greg KH, wmealing; +Cc: linux-kernel, linux-usb
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 [flat|nested] 52+ messages in thread
* Re: [RFC] Create an audit record of USB specific details
2016-04-04 21:37 ` Paul Moore
@ 2016-04-04 21:50 ` Greg KH
2016-04-05 2:54 ` Paul Moore
0 siblings, 1 reply; 52+ messages in thread
From: Greg KH @ 2016-04-04 21:50 UTC (permalink / raw)
To: Paul Moore; +Cc: linux-audit, wmealing, linux-kernel, linux-usb
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 [flat|nested] 52+ messages in thread
* Re: [RFC] Create an audit record of USB specific details
2016-04-04 21:50 ` Greg KH
@ 2016-04-05 2:54 ` Paul Moore
0 siblings, 0 replies; 52+ messages in thread
From: Paul Moore @ 2016-04-05 2:54 UTC (permalink / raw)
To: Greg KH; +Cc: linux-audit, wmealing, linux-kernel, linux-usb
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 [flat|nested] 52+ messages in thread
* Re: [RFC] Create an audit record of USB specific details
@ 2016-04-05 2:54 ` Paul Moore
0 siblings, 0 replies; 52+ messages in thread
From: Paul Moore @ 2016-04-05 2:54 UTC (permalink / raw)
To: Greg KH; +Cc: linux-audit, wmealing, linux-kernel, linux-usb
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.
--
paul moore
www.paul-moore.com
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [RFC] Create an audit record of USB specific details
2016-04-05 2:54 ` Paul Moore
(?)
@ 2016-04-05 3:39 ` Greg KH
[not found] ` <20160405033905.GA14854-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org>
-1 siblings, 1 reply; 52+ messages in thread
From: Greg KH @ 2016-04-05 3:39 UTC (permalink / raw)
To: Paul Moore; +Cc: linux-audit, wmealing, linux-kernel, linux-usb
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 [flat|nested] 52+ messages in thread
* Re: [RFC] Create an audit record of USB specific details
2016-04-04 4:02 [RFC] Create an audit record of USB specific details wmealing
[not found] ` <1459742562-22803-1-git-send-email-wmail-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2016-04-04 12:56 ` Greg KH
@ 2016-04-04 21:37 ` Steve Grubb
2016-04-04 21:54 ` Greg KH
2016-04-04 22:10 ` Burn Alting
2 siblings, 2 replies; 52+ messages in thread
From: Steve Grubb @ 2016-04-04 21:37 UTC (permalink / raw)
To: linux-audit; +Cc: wmealing, linux-usb, linux-kernel
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 [flat|nested] 52+ messages in thread* Re: [RFC] Create an audit record of USB specific details
2016-04-04 21:37 ` Steve Grubb
@ 2016-04-04 21:54 ` Greg KH
2016-04-05 1:51 ` Wade Mealing
2016-04-04 22:10 ` Burn Alting
1 sibling, 1 reply; 52+ messages in thread
From: Greg KH @ 2016-04-04 21:54 UTC (permalink / raw)
To: Steve Grubb; +Cc: linux-audit, wmealing, linux-usb, linux-kernel
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 [flat|nested] 52+ messages in thread
* Re: [RFC] Create an audit record of USB specific details
2016-04-04 21:54 ` Greg KH
@ 2016-04-05 1:51 ` Wade Mealing
2016-04-05 1:54 ` Wade Mealing
0 siblings, 1 reply; 52+ messages in thread
From: Wade Mealing @ 2016-04-05 1:51 UTC (permalink / raw)
To: Greg KH; +Cc: linux-kernel, linux-usb, linux-audit
[-- 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 [flat|nested] 52+ messages in thread
* Re: [RFC] Create an audit record of USB specific details
2016-04-05 1:51 ` Wade Mealing
@ 2016-04-05 1:54 ` Wade Mealing
0 siblings, 0 replies; 52+ messages in thread
From: Wade Mealing @ 2016-04-05 1:54 UTC (permalink / raw)
To: Greg KH; +Cc: linux-kernel, linux-usb, linux-audit
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 [flat|nested] 52+ messages in thread
* Re: [RFC] Create an audit record of USB specific details
@ 2016-04-05 1:54 ` Wade Mealing
0 siblings, 0 replies; 52+ messages in thread
From: Wade Mealing @ 2016-04-05 1:54 UTC (permalink / raw)
To: Greg KH; +Cc: Steve Grubb, linux-audit, linux-usb, linux-kernel
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
>
>
^ permalink raw reply [flat|nested] 52+ messages in thread
[parent not found: <CALJHwhSaimur4w_WqjNOV6dawuDTvqQ5KGM52741Hq=DYMHaAQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: [RFC] Create an audit record of USB specific details
2016-04-05 1:54 ` Wade Mealing
@ 2016-04-05 2:43 ` Greg KH
-1 siblings, 0 replies; 52+ messages in thread
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
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 [flat|nested] 52+ messages in thread
* Re: [RFC] Create an audit record of USB specific details
2016-04-05 1:54 ` Wade Mealing
@ 2016-04-05 2:47 ` Greg KH
-1 siblings, 0 replies; 52+ messages in thread
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
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 [flat|nested] 52+ messages in thread
* Re: [RFC] Create an audit record of USB specific details
@ 2016-04-05 2:47 ` Greg KH
0 siblings, 0 replies; 52+ messages in thread
From: Greg KH @ 2016-04-05 2:47 UTC (permalink / raw)
To: Wade Mealing; +Cc: Steve Grubb, linux-audit, linux-usb, linux-kernel
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
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [RFC] Create an audit record of USB specific details
2016-04-04 21:37 ` Steve Grubb
2016-04-04 21:54 ` Greg KH
@ 2016-04-04 22:10 ` Burn Alting
1 sibling, 0 replies; 52+ messages in thread
From: Burn Alting @ 2016-04-04 22:10 UTC (permalink / raw)
To: Steve Grubb; +Cc: linux-audit, linux-usb, linux-kernel
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 [flat|nested] 52+ messages in thread
end of thread, other threads:[~2016-04-05 22:39 UTC | newest]
Thread overview: 52+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-04-04 4:02 [RFC] Create an audit record of USB specific details wmealing
[not found] ` <1459742562-22803-1-git-send-email-wmail-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2016-04-04 6:48 ` Oliver Neukum
2016-04-04 6:48 ` Oliver Neukum
[not found] ` <1459752519.24025.5.camel-IBi9RG/b67k@public.gmane.org>
2016-04-04 7:47 ` Bjørn Mork
2016-04-04 7:47 ` Bjørn Mork
[not found] ` <87bn5pzuh1.fsf-lbf33ChDnrE/G1V5fR+Y7Q@public.gmane.org>
2016-04-05 8:40 ` Wade Mealing
2016-04-05 8:40 ` Wade Mealing
2016-04-05 11:49 ` EXT :Re: " Boyce, Kevin P (AS)
2016-04-05 13:46 ` Greg KH
2016-04-05 13:52 ` Boyce, Kevin P (AS)
[not found] ` <6bdd24ee68e64e4e91fa160940d357ed-cZmdoFAsBjDgAiKnVY1dJgQSgKfZeEaX@public.gmane.org>
2016-04-05 15:35 ` Greg KH
2016-04-05 15:35 ` Greg KH
2016-04-05 14:40 ` Alan Stern
2016-04-05 22:17 ` Wade Mealing
2016-04-05 17:02 ` Oliver Neukum
[not found] ` <1459875768.2892.1.camel-IBi9RG/b67k@public.gmane.org>
2016-04-05 19:38 ` Steve Grubb
2016-04-05 19:38 ` Steve Grubb
2016-04-05 22:18 ` Greg KH
2016-04-04 12:56 ` Greg KH
2016-04-04 21:33 ` Steve Grubb
2016-04-04 21:48 ` Greg KH
[not found] ` <20160404214843.GA26580-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org>
2016-04-04 21:53 ` Greg KH
2016-04-04 21:53 ` Greg KH
2016-04-05 13:07 ` Burn Alting
2016-04-05 13:44 ` Greg KH
2016-04-05 14:08 ` Burn Alting
2016-04-05 14:08 ` Burn Alting
2016-04-05 14:20 ` EXT :Re: " Boyce, Kevin P (AS)
2016-04-05 14:20 ` Boyce, Kevin P (AS)
[not found] ` <9dd2354558314ead819366b954e97133-cZmdoFAsBjDgAiKnVY1dJgQSgKfZeEaX@public.gmane.org>
2016-04-05 14:37 ` Burn Alting
2016-04-05 14:37 ` Burn Alting
[not found] ` <1459867036.7998.112.camel-krJecHFEUit3UMzaYwuTPmD2FQJk+8+b@public.gmane.org>
2016-04-05 14:42 ` Boyce, Kevin P (AS)
2016-04-05 14:42 ` Boyce, Kevin P (AS)
[not found] ` <ffef94ad8d7a4770a4a192488a5be1c3-cZmdoFAsBjDgAiKnVY1dJgQSgKfZeEaX@public.gmane.org>
2016-04-05 22:39 ` Burn Alting
2016-04-05 22:39 ` Burn Alting
2016-04-04 21:37 ` Paul Moore
2016-04-04 21:50 ` Greg KH
2016-04-05 2:54 ` Paul Moore
2016-04-05 2:54 ` Paul Moore
2016-04-05 3:39 ` Greg KH
[not found] ` <20160405033905.GA14854-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org>
2016-04-05 14:50 ` Paul Moore
2016-04-05 14:50 ` Paul Moore
2016-04-04 21:37 ` Steve Grubb
2016-04-04 21:54 ` Greg KH
2016-04-05 1:51 ` Wade Mealing
2016-04-05 1:54 ` Wade Mealing
2016-04-05 1:54 ` Wade Mealing
[not found] ` <CALJHwhSaimur4w_WqjNOV6dawuDTvqQ5KGM52741Hq=DYMHaAQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-04-05 2:43 ` Greg KH
2016-04-05 2:43 ` Greg KH
2016-04-05 2:47 ` Greg KH
2016-04-05 2:47 ` Greg KH
2016-04-04 22:10 ` Burn Alting
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.