* [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; 36+ 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] 36+ 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 [not found] ` <1459742562-22803-1-git-send-email-wmail-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> @ 2016-04-04 6:48 ` Oliver Neukum [not found] ` <1459752519.24025.5.camel-IBi9RG/b67k@public.gmane.org> 0 siblings, 1 reply; 36+ 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] 36+ 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 [not found] ` <1459752519.24025.5.camel-IBi9RG/b67k@public.gmane.org> @ 2016-04-04 7:47 ` Bjørn Mork [not found] ` <87bn5pzuh1.fsf-lbf33ChDnrE/G1V5fR+Y7Q@public.gmane.org> 0 siblings, 1 reply; 36+ 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] 36+ messages in thread
[parent not found: <87bn5pzuh1.fsf-lbf33ChDnrE/G1V5fR+Y7Q@public.gmane.org>]
* Re: [RFC] Create an audit record of USB specific details [not found] ` <87bn5pzuh1.fsf-lbf33ChDnrE/G1V5fR+Y7Q@public.gmane.org> @ 2016-04-05 8:40 ` Wade Mealing 2016-04-05 11:49 ` EXT :Re: " Boyce, Kevin P (AS) ` (2 more replies) 0 siblings, 3 replies; 36+ 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] 36+ 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 2016-04-05 14:40 ` Alan Stern 2016-04-05 17:02 ` Oliver Neukum 2 siblings, 1 reply; 36+ 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] 36+ 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; 36+ 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] 36+ 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; 36+ 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] 36+ messages in thread
[parent not found: <6bdd24ee68e64e4e91fa160940d357ed-cZmdoFAsBjDgAiKnVY1dJgQSgKfZeEaX@public.gmane.org>]
* Re: EXT :Re: [RFC] Create an audit record of USB specific details [not found] ` <6bdd24ee68e64e4e91fa160940d357ed-cZmdoFAsBjDgAiKnVY1dJgQSgKfZeEaX@public.gmane.org> @ 2016-04-05 15:35 ` Greg KH 0 siblings, 0 replies; 36+ messages in thread From: Greg KH @ 2016-04-05 15:35 UTC (permalink / raw) To: Boyce, Kevin P (AS) Cc: Wade Mealing, Bjørn Mork, Oliver Neukum, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-usb, linux-audit-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org On Tue, Apr 05, 2016 at 01:52:40PM +0000, Boyce, Kevin P (AS) wrote: > 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. Ok, but watch out, lots of USB devices don't have a device node, they get accessed directly by userspace applications, using the kernel as a "raw" pass-through. It's not an easy problem, good luck all! 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] 36+ messages in thread
* Re: [RFC] Create an audit record of USB specific details 2016-04-05 8:40 ` Wade Mealing 2016-04-05 11:49 ` EXT :Re: " Boyce, Kevin P (AS) @ 2016-04-05 14:40 ` Alan Stern 2016-04-05 22:17 ` Wade Mealing 2016-04-05 17:02 ` Oliver Neukum 2 siblings, 1 reply; 36+ 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] 36+ 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; 36+ 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] 36+ messages in thread
* Re: [RFC] Create an audit record of USB specific details 2016-04-05 8:40 ` Wade Mealing 2016-04-05 11:49 ` EXT :Re: " Boyce, Kevin P (AS) 2016-04-05 14:40 ` Alan Stern @ 2016-04-05 17:02 ` Oliver Neukum [not found] ` <1459875768.2892.1.camel-IBi9RG/b67k@public.gmane.org> 2 siblings, 1 reply; 36+ 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] 36+ messages in thread
[parent not found: <1459875768.2892.1.camel-IBi9RG/b67k@public.gmane.org>]
* Re: [RFC] Create an audit record of USB specific details [not found] ` <1459875768.2892.1.camel-IBi9RG/b67k@public.gmane.org> @ 2016-04-05 19:38 ` Steve Grubb 2016-04-05 22:18 ` Greg KH 0 siblings, 1 reply; 36+ messages in thread From: Steve Grubb @ 2016-04-05 19:38 UTC (permalink / raw) To: linux-audit-H+wXaHxf7aLQT0dZR+AlfA Cc: Oliver Neukum, Wade Mealing, linux-usb, linux-kernel-u79uwXL29TY76Z2rM5mHXA, bjorn-yOkvZcmFvRU On Tuesday, April 05, 2016 07:02:48 PM Oliver Neukum wrote: > 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. If this was going to be done in user space, then we are talking about auditd growing the ability to monitor another netlink socket for events. The question that decides if this is feasible is whether or not UEVENTS are protected from loss if several occur in a short time before auditd can get around to reading them. The other issue that I'm curious about is if adding hardware can fail. Do the events coming out by UEVENTS have any sense of pass or fail? Or are they all implicitly successful? And then we get to the issue of whether or not UEVENTS can be filtered. If so, then we will also need to add auditing around the configuration of the filters to see if anything is impacting the audit trail. -Steve -- 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] 36+ messages in thread
* Re: [RFC] Create an audit record of USB specific details 2016-04-05 19:38 ` Steve Grubb @ 2016-04-05 22:18 ` Greg KH 0 siblings, 0 replies; 36+ messages in thread From: Greg KH @ 2016-04-05 22:18 UTC (permalink / raw) To: Steve Grubb Cc: linux-audit, Oliver Neukum, Wade Mealing, linux-usb, linux-kernel, bjorn On Tue, Apr 05, 2016 at 03:38:34PM -0400, Steve Grubb wrote: > On Tuesday, April 05, 2016 07:02:48 PM Oliver Neukum wrote: > > 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. > > If this was going to be done in user space, then we are talking about auditd > growing the ability to monitor another netlink socket for events. The question > that decides if this is feasible is whether or not UEVENTS are protected from > loss if several occur in a short time before auditd can get around to reading > them. udevd should queue up your events that you subscribe to just fine. Test it out if you want to, it should be pretty easy. > The other issue that I'm curious about is if adding hardware can fail. Sure it can, plug in a "broken" USB device and watch it not enumerate properly :) > Do the events coming out by UEVENTS have any sense of pass or fail? Or > are they all implicitly successful? They only happen when a device is successfully added to the kernel. > And then we get to the issue of whether or not UEVENTS can be filtered. If so, > then we will also need to add auditing around the configuration of the filters > to see if anything is impacting the audit trail. You can filter in userspace, that's what udevd provides for you today. thanks, greg k-h ^ permalink raw reply [flat|nested] 36+ 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; 36+ 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] 36+ 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; 36+ 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] 36+ 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; 36+ 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] 36+ messages in thread
[parent not found: <20160404214843.GA26580-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org>]
* Re: [RFC] Create an audit record of USB specific details [not found] ` <20160404214843.GA26580-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org> @ 2016-04-04 21:53 ` Greg KH 2016-04-05 13:07 ` Burn Alting 0 siblings, 1 reply; 36+ messages in thread 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 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 [flat|nested] 36+ messages in thread
* Re: [RFC] Create an audit record of USB specific details 2016-04-04 21:53 ` Greg KH @ 2016-04-05 13:07 ` Burn Alting 2016-04-05 13:44 ` Greg KH 0 siblings, 1 reply; 36+ messages in thread From: Burn Alting @ 2016-04-05 13:07 UTC (permalink / raw) To: Greg KH; +Cc: Steve Grubb, linux-audit, linux-kernel, linux-usb 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 [flat|nested] 36+ messages in thread
* Re: [RFC] Create an audit record of USB specific details 2016-04-05 13:07 ` Burn Alting @ 2016-04-05 13:44 ` Greg KH 2016-04-05 14:08 ` Burn Alting 0 siblings, 1 reply; 36+ messages in thread From: Greg KH @ 2016-04-05 13:44 UTC (permalink / raw) To: Burn Alting; +Cc: Steve Grubb, linux-audit, linux-kernel, linux-usb 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 [flat|nested] 36+ messages in thread
* Re: [RFC] Create an audit record of USB specific details 2016-04-05 13:44 ` Greg KH @ 2016-04-05 14:08 ` Burn Alting 2016-04-05 14:20 ` EXT :Re: " Boyce, Kevin P (AS) 0 siblings, 1 reply; 36+ messages in thread From: Burn Alting @ 2016-04-05 14:08 UTC (permalink / raw) To: Greg KH; +Cc: linux-kernel, linux-usb, linux-audit 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 [flat|nested] 36+ messages in thread
* RE: EXT :Re: [RFC] Create an audit record of USB specific details 2016-04-05 14:08 ` Burn Alting @ 2016-04-05 14:20 ` Boyce, Kevin P (AS) [not found] ` <9dd2354558314ead819366b954e97133-cZmdoFAsBjDgAiKnVY1dJgQSgKfZeEaX@public.gmane.org> 0 siblings, 1 reply; 36+ messages in thread 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 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 [flat|nested] 36+ messages in thread
[parent not found: <9dd2354558314ead819366b954e97133-cZmdoFAsBjDgAiKnVY1dJgQSgKfZeEaX@public.gmane.org>]
* RE: EXT :Re: [RFC] Create an audit record of USB specific details [not found] ` <9dd2354558314ead819366b954e97133-cZmdoFAsBjDgAiKnVY1dJgQSgKfZeEaX@public.gmane.org> @ 2016-04-05 14:37 ` Burn Alting [not found] ` <1459867036.7998.112.camel-krJecHFEUit3UMzaYwuTPmD2FQJk+8+b@public.gmane.org> 0 siblings, 1 reply; 36+ messages in thread 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 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 [flat|nested] 36+ messages in thread
[parent not found: <1459867036.7998.112.camel-krJecHFEUit3UMzaYwuTPmD2FQJk+8+b@public.gmane.org>]
* RE: EXT :Re: [RFC] Create an audit record of USB specific details [not found] ` <1459867036.7998.112.camel-krJecHFEUit3UMzaYwuTPmD2FQJk+8+b@public.gmane.org> @ 2016-04-05 14:42 ` Boyce, Kevin P (AS) [not found] ` <ffef94ad8d7a4770a4a192488a5be1c3-cZmdoFAsBjDgAiKnVY1dJgQSgKfZeEaX@public.gmane.org> 0 siblings, 1 reply; 36+ messages in thread From: Boyce, Kevin P (AS) @ 2016-04-05 14:42 UTC (permalink / raw) To: burn-VQrJuM5UdZBN0TnZuCh8vA@public.gmane.org Cc: Greg KH, linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-audit-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain; charset="utf-8", Size: 933 bytes --] Burn, > 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 And even when you try to figure this out for a CD it is next to impossible to know what is written. If I remember correctly when running strace on wodim you don't ever see the write() calls on the filenames. And instead, what if someone creates an iso image and burns that to a DVD. You really have no way of knowing what is on that disc. When the burn process is complete, the disc usually gets ejected, so the audit subsystem would never even get a chance to evaluate the filesystem that was written to optical media. Kevin N§²æìr¸yúèØb²X¬¶Ç§vØ^)Þº{.nÇ+·¥{±ºÆâØ^nr¡ö¦zË\x1aëh¨èÚ&¢îý»\x05ËÛÔØï¦v¬Îf\x1dp)¹¹br ê+Ê+zf£¢·h§~Ûiÿûàz¹\x1e®w¥¢¸?¨èÚ&¢)ߢ^[f ^ permalink raw reply [flat|nested] 36+ messages in thread
[parent not found: <ffef94ad8d7a4770a4a192488a5be1c3-cZmdoFAsBjDgAiKnVY1dJgQSgKfZeEaX@public.gmane.org>]
* RE: EXT :Re: [RFC] Create an audit record of USB specific details [not found] ` <ffef94ad8d7a4770a4a192488a5be1c3-cZmdoFAsBjDgAiKnVY1dJgQSgKfZeEaX@public.gmane.org> @ 2016-04-05 22:39 ` Burn Alting 0 siblings, 0 replies; 36+ messages in thread From: Burn Alting @ 2016-04-05 22:39 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 On Tue, 2016-04-05 at 14:42 +0000, Boyce, Kevin P (AS) wrote: > Burn, > > > 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 > > And even when you try to figure this out for a CD it is next to impossible to know what is written. If I remember correctly when running strace on wodim you don't ever see the write() calls on the filenames. And instead, what if someone creates an iso image and burns that to a DVD. You really have no way of knowing what is on that disc. When the burn process is complete, the disc usually gets ejected, so the audit subsystem would never even get a chance to evaluate the filesystem that was written to optical media. Two issues here. 1. If you need to know what has been transferred to removable media, then use appropriate DLP (data loss prevention) capability that, not only provides management on who/what can be involved in transfers, but can also keep shadow copies of data transferred. 2. If no DLP tools are available, then we need to make use of audit but we do not rely on a single event in isolation. Reviewing events both before and after a removable media event, along with events from other services (web servers, applications) allows one to build a 'balance of probabilities' picture of what has occurred. (The balance of probabilities is improved with more information of value and it's integrity). Apologies for going off topic on theses lists, but I am hoping this background to our requirements will aid in any further discussion regarding solutions people such as Wade are investigating. If there is a desire to continue, it's probably best we move such discussions to audit specific lists or dedicated forums and return when required with kernel/usb specific issues. Regards Burn -- 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] 36+ 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; 36+ 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] 36+ 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; 36+ 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] 36+ 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 2016-04-05 3:39 ` Greg KH 0 siblings, 1 reply; 36+ 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] 36+ 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> 0 siblings, 1 reply; 36+ 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] 36+ messages in thread
[parent not found: <20160405033905.GA14854-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org>]
* Re: [RFC] Create an audit record of USB specific details [not found] ` <20160405033905.GA14854-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org> @ 2016-04-05 14:50 ` Paul Moore 0 siblings, 0 replies; 36+ messages in thread From: Paul Moore @ 2016-04-05 14:50 UTC (permalink / raw) To: Greg KH Cc: linux-audit-H+wXaHxf7aLQT0dZR+AlfA, wmealing, linux-kernel-u79uwXL29TY76Z2rM5mHXA, linux-usb-u79uwXL29TY76Z2rM5mHXA On Mon, Apr 4, 2016 at 11:39 PM, Greg KH <gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org> wrote: > On Mon, Apr 04, 2016 at 10:54:56PM -0400, Paul Moore wrote: >> On April 4, 2016 6:17:23 PM Greg KH <gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.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-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. >> > > >> > > 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? If the kernel isn't able to send a message to userspace, either due to a netlink failure or some userspace failure, how is the kernel going to reliably notify userspace to panic the system? >> > > 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? As I mentioned earlier, this bit about restricting access to uevents was largely me thinking out loud and had to do with protecting the integrity of the audit log from invalid uevent records. It isn't important to the larger discussion and I believe I've sorted it in my head anyway. Regardless, I think Wade and Burn have done a pretty good job explaining the larger picture of what they are trying to do, I guess my question to you is what don't you understand about their explanations? >> > > 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... Not presently, but if they are tasked with preserving the integrity of the audit events then they would care. However, as I typed above, this isn't something worth worrying about right now and is likely just a distraction. -- paul moore www.paul-moore.com -- 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] 36+ 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; 36+ 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] 36+ 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; 36+ 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] 36+ 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; 36+ 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] 36+ 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 [not found] ` <CALJHwhSaimur4w_WqjNOV6dawuDTvqQ5KGM52741Hq=DYMHaAQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 0 siblings, 1 reply; 36+ 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] 36+ messages in thread
[parent not found: <CALJHwhSaimur4w_WqjNOV6dawuDTvqQ5KGM52741Hq=DYMHaAQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: [RFC] Create an audit record of USB specific details [not found] ` <CALJHwhSaimur4w_WqjNOV6dawuDTvqQ5KGM52741Hq=DYMHaAQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> @ 2016-04-05 2:43 ` Greg KH 2016-04-05 2:47 ` Greg KH 1 sibling, 0 replies; 36+ 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] 36+ messages in thread
* Re: [RFC] Create an audit record of USB specific details [not found] ` <CALJHwhSaimur4w_WqjNOV6dawuDTvqQ5KGM52741Hq=DYMHaAQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2016-04-05 2:43 ` Greg KH @ 2016-04-05 2:47 ` Greg KH 1 sibling, 0 replies; 36+ 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] 36+ 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; 36+ 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] 36+ messages in thread
end of thread, other threads:[~2016-04-05 22:39 UTC | newest]
Thread overview: 36+ 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
[not found] ` <1459752519.24025.5.camel-IBi9RG/b67k@public.gmane.org>
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 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 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 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-05 13:07 ` Burn Alting
2016-04-05 13:44 ` Greg KH
2016-04-05 14:08 ` Burn Alting
2016-04-05 14:20 ` EXT :Re: " Boyce, Kevin P (AS)
[not found] ` <9dd2354558314ead819366b954e97133-cZmdoFAsBjDgAiKnVY1dJgQSgKfZeEaX@public.gmane.org>
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)
[not found] ` <ffef94ad8d7a4770a4a192488a5be1c3-cZmdoFAsBjDgAiKnVY1dJgQSgKfZeEaX@public.gmane.org>
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 3:39 ` Greg KH
[not found] ` <20160405033905.GA14854-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org>
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
[not found] ` <CALJHwhSaimur4w_WqjNOV6dawuDTvqQ5KGM52741Hq=DYMHaAQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-04-05 2:43 ` Greg KH
2016-04-05 2:47 ` Greg KH
2016-04-04 22:10 ` Burn Alting
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox