RE: EXT :Re: [RFC] Create an audit record of USB specific details
On Tue, 2016-04-05 at 14:42 +, 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
RE: EXT :Re: [RFC] Create an audit record of USB specific details
On Tue, 2016-04-05 at 14:20 +, 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-boun...@redhat.com [mailto:linux-audit-boun...@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-...@vger.kernel.org; > linux-au...@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 > > > > > > > > > > > > > > > > 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 / 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 an
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 > > > > > > > > > > > > > > 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 / > > > > > > 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
Re: [RFC] Create an audit record of USB specific details
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 > > > > > > > > > > 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 / 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
Re: [RFC] Create an audit record of USB specific details
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=: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.
BUG: stallion module cannot register it's ISR in a 2.6.10 kernel on a FC3 system
Here is the bug report. Stallion was purchased by Lantronix and they don't really care about this bug. [1.] One line summary of the problem: Stallion 4 port IO card fails when modprobe'd into kernel [2.] Full description of the problem/report: Under Fedora Core 3 using a ftp.kernel.org 2.6.10 kernel, when the stallion driver module is loaded into the kernel error messages appear in /var/log/messages. Then, if a port is accessed further messages appear and IRQ 11 is disabled/turned off. [3.] Keywords (i.e., modules, networking, kernel): stallion, serial, kernel [4.] Kernel version (from /proc/version): Linux version 2.6.10 ([EMAIL PROTECTED]) (gcc version 3.4.2 20041017 (Red Hat 3.4.2-6.fc3)) #1 Fri Feb 18 17:44:05 EST 2005 [5.] Output of Oops.. message (if applicable) with symbolic information resolved (see Documentation/oops-tracing.txt) [6.] A small shell script or example program which triggers the problem (if possible) modprobe stallion [7.] Environment [7.1.] Software (add the output of the ver_linux script here) Linux swtf.comptex.com.au 2.6.10 #1 Fri Feb 18 17:44:05 EST 2005 i686 i686 i386 GNU/Linux Gnu C 3.4.2 Gnu make 3.80 binutils 2.15.92.0.2 util-linux 2.12a mount 2.12a module-init-tools 3.1-pre5 e2fsprogs 1.35 jfsutils 1.1.7 reiserfsprogs 3.6.18 reiser4progs line xfsprogs 2.6.13 pcmcia-cs 3.2.7 quota-tools3.12. PPP2.4.2 isdn4k-utils 3.3 nfs-utils 1.0.6 Linux C Library2.3.4 Dynamic linker (ldd) 2.3.4 Procps 3.2.3 Net-tools 1.60 Kbd1.12 Sh-utils 5.2.1 Modules Loaded nfsd exportfs lockd parport_pc lp parport autofs4 sunrpc dm_mod video button battery ac pl2303 ftdi_sio usbserial md5 ipv6 uhci_hcd ehci_hcd i2c_i801 i2c_core snd_usb_audio snd_usb_lib snd_rawmidi snd_seq_device snd_intel8x0 snd_ac97_codec snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd soundcore snd_page_alloc e1000 floppy ext3 jbd aic7xxx sd_mod scsi_mod [7.2.] Processor information (from /proc/cpuinfo): processor : 0 vendor_id : GenuineIntel cpu family : 15 model : 2 model name : Intel(R) Pentium(R) 4 CPU 2.53GHz stepping: 4 cpu MHz : 2546.579 cache size : 512 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm bogomips: 5046.27 [7.3.] Module information (from /proc/modules): nfsd 210976 9 - Live 0xf8ccb000 exportfs 9344 1 nfsd, Live 0xf8c8a000 lockd 68264 2 nfsd, Live 0xf8c5a000 parport_pc 29636 1 - Live 0xf8c51000 lp 13292 0 - Live 0xf8c6d000 parport 41928 2 parport_pc,lp, Live 0xf8cbf000 autofs4 28292 0 - Live 0xf8a06000 sunrpc 182372 19 nfsd,lockd, Live 0xf8c23000 dm_mod 64276 0 - Live 0xf89ec000 video 16132 0 - Live 0xf89e7000 button 6928 0 - Live 0xf8a0 battery 9604 0 - Live 0xf89c9000 ac 5124 0 - Live 0xf883d000 pl2303 24964 0 - Live 0xf89c1000 ftdi_sio 33796 0 - Live 0xf89b7000 usbserial 30312 2 pl2303,ftdi_sio, Live 0xf8985000 md5 4608 1 - Live 0xf893d000 ipv6 273088 22 - Live 0xf8d85000 uhci_hcd 36112 0 - Live 0xf89ad000 ehci_hcd 41732 0 - Live 0xf89a1000 i2c_i801 8844 0 - Live 0xf897a000 i2c_core 23040 1 i2c_i801, Live 0xf8973000 snd_usb_audio 67904 2 - Live 0xf8961000 snd_usb_lib 13824 1 snd_usb_audio, Live 0xf898 snd_rawmidi 29984 1 snd_usb_lib, Live 0xf8998000 snd_seq_device 9484 1 snd_rawmidi, Live 0xf8939000 snd_intel8x0 36768 2 - Live 0xf898e000 snd_ac97_codec 76000 1 snd_intel8x0, Live 0xf89cd000 snd_pcm_oss 55588 0 - Live 0xf892a000 snd_mixer_oss 19968 3 snd_pcm_oss, Live 0xf8884000 snd_pcm 110856 4 snd_usb_audio,snd_intel8x0,snd_ac97_codec,snd_pcm_oss, Live 0xf8a1 snd_timer 34692 1 snd_pcm, Live 0xf892 snd 60260 13 snd_usb_audio,snd_rawmidi,snd_seq_device,snd_intel8x0,snd_ac97_codec,snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_timer, Live 0xf88ed000 soundcore 11360 3 snd, Live 0xf888 snd_page_alloc 10372 2 snd_intel8x0,snd_pcm, Live 0xf8864000 e1000 88756 0 - Live 0xf88d6000 floppy 66736 0 - Live 0xf886e000 ext3 134280 3 - Live 0xf88fe000 jbd 86808 1 ext3, Live 0xf888a000 aic7xxx 184024 0 - Live 0xf88a8000 sd_mod 18944 0 - Live 0xf8868000 scsi_mod 136320 2 aic7xxx,sd_mod, Live 0xf881a000 [7.4.] Loaded driver and hardware information (/proc/ioports, /proc/iomem) -001f : dma1 0020-0021 : pic1 0040-0043 : timer0 0050-0053 : timer1 0060-006f : keyboard 0070-0077 : rtc 0080-008f : dma page reg 00a0-00a1 : pic2 00c0-00df : dma2 00f0-00ff : fpu 0170-0177 : ide1 01f0-01f7 : ide0 02f8-02ff : serial 0376-0376 : ide1 0378-037a
