From: Wade Mealing <[email protected]>
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
On Mon, 2016-04-04 at 00:02 -0400, wmealing wrote:
> From: Wade Mealing <[email protected]>
>
> 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
Oliver Neukum <[email protected]> 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
On Mon, Apr 04, 2016 at 12:02:42AM -0400, wmealing wrote:
> From: Wade Mealing <[email protected]>
>
> 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
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 <[email protected]>
> >
> > 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
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.
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 <[email protected]>
> >
> > 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
http://www.paul-moore.com
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 <[email protected]>
> > >
> > > 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
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
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.
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 <[email protected]>
> > >
> > > 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
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 <[email protected]>
> > > >
> > > > 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
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 <[email protected]> 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 <[email protected]> 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
>
>
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?
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
On April 4, 2016 6:17:23 PM Greg KH <[email protected]> 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 <[email protected]>
>> > >
>> > > Gday,
>> > >
>> > > I'm looking to create an audit trail for when devices are added or removed
>> > > from the system.
>> >
>> > Then please do it in userspace, as I suggested before, that way you
>> > catch all types of devices, not just USB ones.
>>
>> Audit has some odd requirements placed on it by some of its users. I think
>> most notable in this particular case is the need to take specific actions,
>> including panicking the system, when audit records can't be sent to userspace
>> and are "lost". Granted, it's an odd requirement, definitely not the
>> norm/default configuration, but supporting weird stuff like this has allowed
>> Linux to be used on some pretty interesting systems that wouldn't have been
>> possible otherwise. Looking quickly at some of the kobject/uvent code, it
>> doesn't appear that the uevent/netlink channel has this capability.
>
> Are you sure you can loose netlink messages? If you do, you know you
> lost them, so isn't that good enough?
Last I checked netlink didn't have a provision for panicking the system, so
no :)
>> It also just noticed that it looks like userspace can send fake uevent
>> messages;
>
> That's how your machine boots properly :)
Yes, it looks like that is how the initial devices are handled, right?
Allowing something like that is probably okay for a variety of reasons, but
I expect users would want to restrict access beyond this single trusted
process. The good news is that I think you should be able to do that with
a combination of DAC and MAC.
>> I haven't looked at it closely enough yet, but that may be a concern
>> for users which restrict/subdivide root using a LSM ... although it is
>> possible that the LSM policy could help here. I'm thinking aloud a bit right
>> now, but for SELinux the netlink controls aren't very granular and sysfs can
>> be tricky so I can't say for certain about blocking fake events from userspace
>> using LSMs/SELinux.
>
> uevents are not tied into LSMs from what I can tell, so I don't
> understand wht you are talking about here, sorry.
Perhaps I'm mistaken, but uevents are sent to userspace via netlink which
does have LSM controls. There also appears to be a file I/O mechanism via
sysfs which also has LSM controls.
--
paul moore
http://www.paul-moore.com
On Mon, Apr 04, 2016 at 10:54:56PM -0400, Paul Moore wrote:
> On April 4, 2016 6:17:23 PM Greg KH <[email protected]> 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 <[email protected]>
> > > > >
> > > > > 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
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
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: [email protected] [mailto:[email protected]] On Behalf Of Wade Mealing
Sent: Tuesday, April 05, 2016 4:40 AM
To: Bj?rn Mork
Cc: Oliver Neukum; [email protected]; linux-usb; [email protected]
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
[email protected]
https://www.redhat.com/mailman/listinfo/linux-audit
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 <[email protected]>
> > > > >
> > > > > 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
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 <[email protected]>
> > > > > >
> > > > > > 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
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
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
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: [email protected] [mailto:[email protected]] On Behalf Of Burn Alting
Sent: Tuesday, April 05, 2016 10:08 AM
To: Greg KH
Cc: [email protected]; [email protected]; [email protected]
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 <[email protected]>
> > > > > > >
> > > > > > > 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
--
Linux-audit mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/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 <[email protected]>
> > > > > > >
> > > > > > > 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
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: [email protected] [mailto:[email protected]] On Behalf Of Burn Alting
> Sent: Tuesday, April 05, 2016 10:08 AM
> To: Greg KH
> Cc: [email protected]; [email protected]; [email protected]
> 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 <[email protected]>
> > > > > > > >
> > > > > > > > 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
>
>
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
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
On Mon, Apr 4, 2016 at 11:39 PM, Greg KH <[email protected]> wrote:
> On Mon, Apr 04, 2016 at 10:54:56PM -0400, Paul Moore wrote:
>> On April 4, 2016 6:17:23 PM Greg KH <[email protected]> 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 <[email protected]>
>> > > > >
>> > > > > 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
http://www.paul-moore.com
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
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
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
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.
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
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