Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1370340 > unrolled thread

[RFC] Create an audit record of USB specific details

Back to article view | Back to linux.kernel

Contents

  [RFC] Create an audit record of USB specific details  wmealing <wmealing@redhat.com> - 2016-04-04 06:10 +0200
    Re: [RFC] Create an audit record of USB specific details Oliver Neukum <oneukum@suse.com> - 2016-04-04 08:50 +0200
      Re: [RFC] Create an audit record of USB specific details Bjørn Mork <bjorn@mork.no> - 2016-04-04 09:50 +0200
        Re: [RFC] Create an audit record of USB specific details Wade Mealing <wmealing@redhat.com> - 2016-04-05 10:50 +0200
          RE: EXT :Re: [RFC] Create an audit record of USB specific details "Boyce, Kevin P (AS)" <Kevin.Boyce@ngc.com> - 2016-04-05 14:10 +0200
            Re: EXT :Re: [RFC] Create an audit record of USB specific details Greg KH <gregkh@linuxfoundation.org> - 2016-04-05 15:50 +0200
              RE: EXT :Re: [RFC] Create an audit record of USB specific details "Boyce, Kevin P (AS)" <Kevin.Boyce@ngc.com> - 2016-04-05 16:00 +0200
                Re: EXT :Re: [RFC] Create an audit record of USB specific details Greg KH <gregkh@linuxfoundation.org> - 2016-04-05 17:40 +0200
          Re: [RFC] Create an audit record of USB specific details Alan Stern <stern@rowland.harvard.edu> - 2016-04-05 16:50 +0200
            Re: [RFC] Create an audit record of USB specific details Wade Mealing <wmealing@redhat.com> - 2016-04-06 00:20 +0200
          Re: [RFC] Create an audit record of USB specific details Oliver Neukum <oneukum@suse.com> - 2016-04-05 19:10 +0200
            Re: [RFC] Create an audit record of USB specific details Steve Grubb <sgrubb@redhat.com> - 2016-04-05 21:40 +0200
              Re: [RFC] Create an audit record of USB specific details Greg KH <greg@kroah.com> - 2016-04-06 00:20 +0200
    Re: [RFC] Create an audit record of USB specific details Greg KH <gregkh@linuxfoundation.org> - 2016-04-04 15:00 +0200
      Re: [RFC] Create an audit record of USB specific details Steve Grubb <sgrubb@redhat.com> - 2016-04-04 23:40 +0200
        Re: [RFC] Create an audit record of USB specific details Greg KH <gregkh@linuxfoundation.org> - 2016-04-05 00:20 +0200
          Re: [RFC] Create an audit record of USB specific details Burn Alting <burn@swtf.dyndns.org> - 2016-04-05 15:10 +0200
            Re: [RFC] Create an audit record of USB specific details Greg KH <gregkh@linuxfoundation.org> - 2016-04-05 15:50 +0200
              RE: EXT :Re: [RFC] Create an audit record of USB specific details "Boyce, Kevin P (AS)" <Kevin.Boyce@ngc.com> - 2016-04-05 16:30 +0200
                RE: EXT :Re: [RFC] Create an audit record of USB specific details Burn Alting <burn@swtf.dyndns.org> - 2016-04-05 16:40 +0200
                  RE: EXT :Re: [RFC] Create an audit record of USB specific details "Boyce, Kevin P (AS)" <Kevin.Boyce@ngc.com> - 2016-04-05 16:50 +0200
                    RE: EXT :Re: [RFC] Create an audit record of USB specific details Burn Alting <burn@swtf.dyndns.org> - 2016-04-06 00:50 +0200
              Re: [RFC] Create an audit record of USB specific details Burn Alting <burn@swtf.dyndns.org> - 2016-04-05 16:40 +0200
        Re: [RFC] Create an audit record of USB specific details Greg KH <gregkh@linuxfoundation.org> - 2016-04-05 00:20 +0200
      Re: [RFC] Create an audit record of USB specific details Paul Moore <paul@paul-moore.com> - 2016-04-04 23:40 +0200
        Re: [RFC] Create an audit record of USB specific details Greg KH <gregkh@linuxfoundation.org> - 2016-04-05 00:20 +0200
          Re: [RFC] Create an audit record of USB specific details Paul Moore <paul@paul-moore.com> - 2016-04-05 05:00 +0200
            Re: [RFC] Create an audit record of USB specific details Greg KH <gregkh@linuxfoundation.org> - 2016-04-05 05:40 +0200
              Re: [RFC] Create an audit record of USB specific details Paul Moore <paul@paul-moore.com> - 2016-04-05 17:00 +0200
    Re: [RFC] Create an audit record of USB specific details Steve Grubb <sgrubb@redhat.com> - 2016-04-04 23:40 +0200
      Re: [RFC] Create an audit record of USB specific details Greg KH <greg@kroah.com> - 2016-04-05 00:20 +0200
        Re: [RFC] Create an audit record of USB specific details Wade Mealing <wmealing@redhat.com> - 2016-04-05 04:00 +0200
          Re: [RFC] Create an audit record of USB specific details Greg KH <greg@kroah.com> - 2016-04-05 04:50 +0200
          Re: [RFC] Create an audit record of USB specific details Greg KH <greg@kroah.com> - 2016-04-05 04:50 +0200
      Re: [RFC] Create an audit record of USB specific details Burn Alting <burn@swtf.dyndns.org> - 2016-04-05 00:20 +0200

Page 2 of 2 — ← Prev page 1 [2]

#1371687 — RE: EXT :Re: [RFC] Create an audit record of USB specific details

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

[toc] | [prev] | [next] | [standalone]

#1372046 — RE: EXT :Re: [RFC] Create an audit record of USB specific details

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

[toc] | [prev] | [next] | [standalone]

#1371681

On Tue, 2016-04-05 at 09:44 -0400, Greg KH wrote:
> On Tue, Apr 05, 2016 at 11:07:48PM +1000, Burn Alting wrote:
> > On Mon, 2016-04-04 at 14:53 -0700, Greg KH wrote:
> > > On Mon, Apr 04, 2016 at 02:48:43PM -0700, Greg KH wrote:
> > > > On Mon, Apr 04, 2016 at 05:33:10PM -0400, Steve Grubb wrote:
> > > > > On Monday, April 04, 2016 05:56:26 AM Greg KH wrote:
> > > > > > On Mon, Apr 04, 2016 at 12:02:42AM -0400, wmealing wrote:
> > > > > > > From: Wade Mealing <wmealing@redhat.com>
> > > > > > > 
> > > > > > > Gday,
> > > > > > > 
> > > > > > > I'm looking to create an audit trail for when devices are added or removed
> > > > > > > from the system.
> > > > > > 
> > > > > > Then please do it in userspace, as I suggested before, that way you
> > > > > > catch all types of devices, not just USB ones.
> > > > > > 
> > > > > > Also I don't think you realize that USB interfaces are what are bound to
> > > > > > drivers, not USB devices, so that is going to mess with any attempted
> > > > > > audit trails here.  How are you going to distinguish between the 5
> > > > > > different devices that just got plugged in that all have 0000/0000 as
> > > > > > vid/pid for them because they are "cheap" devices from China, yet do
> > > > > > totally different things because they are different _types_ of devices?
> > > > > 
> > > > > This sounds like vid/pid should be captured in the event.
> > > > 
> > > > The code did that, the point is, vid/pid means nothing in the real
> > > > world.  So why are you going to audit anything based on it? :)
> > > 
> > > Oh wait, it's worse, it is logging strings, which are even more
> > > unreliable than vid/pid values.  It's pretty obvious this has not been
> > > tested on any large batch of real-world devices, or thought through as
> > > to why any of this is even needed at all.
> > > 
> > > So why is this being added?  Who needs/wants this?  What are their
> > > requirements here? 
> > 
> > As a consumer of auditd events for security purposes, the questions I
> > would like answered via the sort of audit framework Wade is putting
> > together are
> > 
> > - when was a (possible) removable media device plugged into a system and
> > what were the device details - perhaps my corporation has a policy on
> > what devices are 'official' and hence one looks for alternatives,
> > and/or,
> 
> How do you determine if a USB device is "official" or not?  What
> attribute(s) are you going to care about that can't be trivially
> spoofed?

One typically can't defeat the knowledgeable and determined person, but
this doesn't mean you don't try. In the windows world, most DLP
capabilities make use of Manufacturer/Model/Serial in combination with
user and system to determine/record access. In the case of Linux audit,
we would be closing the gate after the horse has bolted, but at least we
know it has occurred.

> 
> > - was it there at boot ? (in case someone adds and removes such devices
> > when powered off), and eventually
> 
> What if you booted off of it?

Which means audit could be defeated anyway since one controls the OS,
but again one still needs to try.

> 
> > - has an open for write (or other system calls) occurred on designated
> > removable media? (i.e. what may have been written to removable media -
> > cooked or raw) - Yes, this infers a baseline of what's connected or an
> > efficient means of working out if a device is 'removable' at system call
> > time.
> 
> Yes, determining "removable" is non-trivial, good luck with that :)

I was hoping for a configurable table that could be pre-seeded and
either managed via the audit interface (add/delete/masked). Pre-seed
with well known devices such as cd/dvd, usb mass storage, scsi devices
with the RMB bit set, etc and go from there. We need to start
somewhere ... 


> 
> thanks,
> 
> greg k-h

[toc] | [prev] | [next] | [standalone]

#1370935

On Mon, Apr 04, 2016 at 05:33:10PM -0400, Steve Grubb wrote:
> On Monday, April 04, 2016 05:56:26 AM Greg KH wrote:
> > On Mon, Apr 04, 2016 at 12:02:42AM -0400, wmealing wrote:
> > > From: Wade Mealing <wmealing@redhat.com>
> > > 
> > > Gday,
> > > 
> > > I'm looking to create an audit trail for when devices are added or removed
> > > from the system.
> > 
> > Then please do it in userspace, as I suggested before, that way you
> > catch all types of devices, not just USB ones.
> > 
> > Also I don't think you realize that USB interfaces are what are bound to
> > drivers, not USB devices, so that is going to mess with any attempted
> > audit trails here.  How are you going to distinguish between the 5
> > different devices that just got plugged in that all have 0000/0000 as
> > vid/pid for them because they are "cheap" devices from China, yet do
> > totally different things because they are different _types_ of devices?
> 
> This sounds like vid/pid should be captured in the event.

The code did that, the point is, vid/pid means nothing in the real
world.  So why are you going to audit anything based on it? :)

> > Again, do this in userspace please, that is where it belongs.
> 
> There is one issue that may need some clarification. The audit system has to do 
> everything possible to make sure that an event is captured and logged. Does 
> the uevent netlink protocol ever drop events because the user space queue is 
> full? If the uevent interface drops events, then its not audit quality in 
> terms of doing everything possible to prevent the loss of a record. If this 
> were to happen, how would user space find out when a uevent gets dropped? I may 
> have to panic the machine if that happens depending on the configured policy. 
> So, we need to know when it happens. If on the otherhand it doesn't ever drop 
> events, then it might be usable.

I have never seen it drop events, have you?  It's been pretty reliable
for the past 10+ years :)

thanks,

greg k-h

[toc] | [prev] | [next] | [standalone]

#1370918

On Monday, April 04, 2016 05:56:26 AM Greg KH wrote:
> On Mon, Apr 04, 2016 at 12:02:42AM -0400, wmealing wrote:
> > From: Wade Mealing <wmealing@redhat.com>
> > 
> > Gday,
> > 
> > I'm looking to create an audit trail for when devices are added or removed
> > from the system.
> 
> Then please do it in userspace, as I suggested before, that way you
> catch all types of devices, not just USB ones.

Audit has some odd requirements placed on it by some of its users.  I think 
most notable in this particular case is the need to take specific actions, 
including panicking the system, when audit records can't be sent to userspace 
and are "lost".  Granted, it's an odd requirement, definitely not the 
norm/default configuration, but supporting weird stuff like this has allowed 
Linux to be used on some pretty interesting systems that wouldn't have been 
possible otherwise.  Looking quickly at some of the kobject/uvent code, it 
doesn't appear that the uevent/netlink channel has this capability.

It also just noticed that it looks like userspace can send fake uevent 
messages; I haven't looked at it closely enough yet, but that may be a concern 
for users which restrict/subdivide root using a LSM ... although it is 
possible that the LSM policy could help here.  I'm thinking aloud a bit right 
now, but for SELinux the netlink controls aren't very granular and sysfs can 
be tricky so I can't say for certain about blocking fake events from userspace 
using LSMs/SELinux.

-- 
paul moore
www.paul-moore.com

[toc] | [prev] | [next] | [standalone]

#1370937

On Mon, Apr 04, 2016 at 05:37:58PM -0400, Paul Moore wrote:
> On Monday, April 04, 2016 05:56:26 AM Greg KH wrote:
> > On Mon, Apr 04, 2016 at 12:02:42AM -0400, wmealing wrote:
> > > From: Wade Mealing <wmealing@redhat.com>
> > > 
> > > Gday,
> > > 
> > > I'm looking to create an audit trail for when devices are added or removed
> > > from the system.
> > 
> > Then please do it in userspace, as I suggested before, that way you
> > catch all types of devices, not just USB ones.
> 
> Audit has some odd requirements placed on it by some of its users.  I think 
> most notable in this particular case is the need to take specific actions, 
> including panicking the system, when audit records can't be sent to userspace 
> and are "lost".  Granted, it's an odd requirement, definitely not the 
> norm/default configuration, but supporting weird stuff like this has allowed 
> Linux to be used on some pretty interesting systems that wouldn't have been 
> possible otherwise.  Looking quickly at some of the kobject/uvent code, it 
> doesn't appear that the uevent/netlink channel has this capability.

Are you sure you can loose netlink messages?  If you do, you know you
lost them, so isn't that good enough?

> It also just noticed that it looks like userspace can send fake uevent 
> messages;

That's how your machine boots properly :)

> I haven't looked at it closely enough yet, but that may be a concern 
> for users which restrict/subdivide root using a LSM ... although it is 
> possible that the LSM policy could help here.  I'm thinking aloud a bit right 
> now, but for SELinux the netlink controls aren't very granular and sysfs can 
> be tricky so I can't say for certain about blocking fake events from userspace 
> using LSMs/SELinux.

uevents are not tied into LSMs from what I can tell, so I don't
understand wht you are talking about here, sorry.

thanks,

greg k-h

[toc] | [prev] | [next] | [standalone]

#1371145

On April 4, 2016 6:17:23 PM Greg KH <gregkh@linuxfoundation.org> wrote:
> On Mon, Apr 04, 2016 at 05:37:58PM -0400, Paul Moore wrote:
>> On Monday, April 04, 2016 05:56:26 AM Greg KH wrote:
>> > On Mon, Apr 04, 2016 at 12:02:42AM -0400, wmealing wrote:
>> > > From: Wade Mealing <wmealing@redhat.com>
>> > >
>> > > Gday,
>> > >
>> > > I'm looking to create an audit trail for when devices are added or removed
>> > > from the system.
>> >
>> > Then please do it in userspace, as I suggested before, that way you
>> > catch all types of devices, not just USB ones.
>>
>> Audit has some odd requirements placed on it by some of its users.  I think
>> most notable in this particular case is the need to take specific actions,
>> including panicking the system, when audit records can't be sent to userspace
>> and are "lost".  Granted, it's an odd requirement, definitely not the
>> norm/default configuration, but supporting weird stuff like this has allowed
>> Linux to be used on some pretty interesting systems that wouldn't have been
>> possible otherwise.  Looking quickly at some of the kobject/uvent code, it
>> doesn't appear that the uevent/netlink channel has this capability.
>
> Are you sure you can loose netlink messages?  If you do, you know you
> lost them, so isn't that good enough?

Last I checked netlink didn't have a provision for panicking the system, so 
no :)

>> It also just noticed that it looks like userspace can send fake uevent
>> messages;
>
> That's how your machine boots properly :)

Yes, it looks like that is how the initial devices are handled, right?  
Allowing something like that is probably okay for a variety of reasons, but 
I expect users would want to restrict access beyond this single trusted 
process.  The good news is that I think you should be able to do that with 
a combination of DAC and MAC.

>> I haven't looked at it closely enough yet, but that may be a concern
>> for users which restrict/subdivide root using a LSM ... although it is
>> possible that the LSM policy could help here.  I'm thinking aloud a bit right
>> now, but for SELinux the netlink controls aren't very granular and sysfs can
>> be tricky so I can't say for certain about blocking fake events from userspace
>> using LSMs/SELinux.
>
> uevents are not tied into LSMs from what I can tell, so I don't
> understand wht you are talking about here, sorry.

Perhaps I'm mistaken, but uevents are sent to userspace via netlink which 
does have LSM controls.  There also appears to be a file I/O mechanism via 
sysfs which also has LSM controls.

--
paul moore
www.paul-moore.com

[toc] | [prev] | [next] | [standalone]

#1371164

On Mon, Apr 04, 2016 at 10:54:56PM -0400, Paul Moore wrote:
> On April 4, 2016 6:17:23 PM Greg KH <gregkh@linuxfoundation.org> wrote:
> > On Mon, Apr 04, 2016 at 05:37:58PM -0400, Paul Moore wrote:
> > > On Monday, April 04, 2016 05:56:26 AM Greg KH wrote:
> > > > On Mon, Apr 04, 2016 at 12:02:42AM -0400, wmealing wrote:
> > > > > From: Wade Mealing <wmealing@redhat.com>
> > > > >
> > > > > Gday,
> > > > >
> > > > > I'm looking to create an audit trail for when devices are added or removed
> > > > > from the system.
> > > >
> > > > Then please do it in userspace, as I suggested before, that way you
> > > > catch all types of devices, not just USB ones.
> > > 
> > > Audit has some odd requirements placed on it by some of its users.  I think
> > > most notable in this particular case is the need to take specific actions,
> > > including panicking the system, when audit records can't be sent to userspace
> > > and are "lost".  Granted, it's an odd requirement, definitely not the
> > > norm/default configuration, but supporting weird stuff like this has allowed
> > > Linux to be used on some pretty interesting systems that wouldn't have been
> > > possible otherwise.  Looking quickly at some of the kobject/uvent code, it
> > > doesn't appear that the uevent/netlink channel has this capability.
> > 
> > Are you sure you can loose netlink messages?  If you do, you know you
> > lost them, so isn't that good enough?
> 
> Last I checked netlink didn't have a provision for panicking the system, so
> no :)

Userspace can panic the system if it detects this, so why not just do
that?

> > > It also just noticed that it looks like userspace can send fake uevent
> > > messages;
> > 
> > That's how your machine boots properly :)
> 
> Yes, it looks like that is how the initial devices are handled, right?
> Allowing something like that is probably okay for a variety of reasons, but
> I expect users would want to restrict access beyond this single trusted
> process.  The good news is that I think you should be able to do that with a
> combination of DAC and MAC.

Again, please step back.  What exactly are you trying to do here?  What
is the requirement?

> > > I haven't looked at it closely enough yet, but that may be a concern
> > > for users which restrict/subdivide root using a LSM ... although it is
> > > possible that the LSM policy could help here.  I'm thinking aloud a bit right
> > > now, but for SELinux the netlink controls aren't very granular and sysfs can
> > > be tricky so I can't say for certain about blocking fake events from userspace
> > > using LSMs/SELinux.
> > 
> > uevents are not tied into LSMs from what I can tell, so I don't
> > understand wht you are talking about here, sorry.
> 
> Perhaps I'm mistaken, but uevents are sent to userspace via netlink which
> does have LSM controls.  There also appears to be a file I/O mechanism via
> sysfs which also has LSM controls.

And do any of them look at uevents through these mechanisms?

I doubt they care...

thanks,

greg k-h

[toc] | [prev] | [next] | [standalone]

#1371698

On Mon, Apr 4, 2016 at 11:39 PM, Greg KH <gregkh@linuxfoundation.org> wrote:
> On Mon, Apr 04, 2016 at 10:54:56PM -0400, Paul Moore wrote:
>> On April 4, 2016 6:17:23 PM Greg KH <gregkh@linuxfoundation.org> wrote:
>> > On Mon, Apr 04, 2016 at 05:37:58PM -0400, Paul Moore wrote:
>> > > On Monday, April 04, 2016 05:56:26 AM Greg KH wrote:
>> > > > On Mon, Apr 04, 2016 at 12:02:42AM -0400, wmealing wrote:
>> > > > > From: Wade Mealing <wmealing@redhat.com>
>> > > > >
>> > > > > Gday,
>> > > > >
>> > > > > I'm looking to create an audit trail for when devices are added or removed
>> > > > > from the system.
>> > > >
>> > > > Then please do it in userspace, as I suggested before, that way you
>> > > > catch all types of devices, not just USB ones.
>> > >
>> > > Audit has some odd requirements placed on it by some of its users.  I think
>> > > most notable in this particular case is the need to take specific actions,
>> > > including panicking the system, when audit records can't be sent to userspace
>> > > and are "lost".  Granted, it's an odd requirement, definitely not the
>> > > norm/default configuration, but supporting weird stuff like this has allowed
>> > > Linux to be used on some pretty interesting systems that wouldn't have been
>> > > possible otherwise.  Looking quickly at some of the kobject/uvent code, it
>> > > doesn't appear that the uevent/netlink channel has this capability.
>> >
>> > Are you sure you can loose netlink messages?  If you do, you know you
>> > lost them, so isn't that good enough?
>>
>> Last I checked netlink didn't have a provision for panicking the system, so
>> no :)
>
> Userspace can panic the system if it detects this, so why not just do
> that?

If the kernel isn't able to send a message to userspace, either due to
a netlink failure or some userspace failure, how is the kernel going
to reliably notify userspace to panic the system?

>> > > It also just noticed that it looks like userspace can send fake uevent
>> > > messages;
>> >
>> > That's how your machine boots properly :)
>>
>> Yes, it looks like that is how the initial devices are handled, right?
>> Allowing something like that is probably okay for a variety of reasons, but
>> I expect users would want to restrict access beyond this single trusted
>> process.  The good news is that I think you should be able to do that with a
>> combination of DAC and MAC.
>
> Again, please step back.  What exactly are you trying to do here?  What
> is the requirement?

As I mentioned earlier, this bit about restricting access to uevents
was largely me thinking out loud and had to do with protecting the
integrity of the audit log from invalid uevent records.  It isn't
important to the larger discussion and I believe I've sorted it in my
head anyway.

Regardless, I think Wade and Burn have done a pretty good job
explaining the larger picture of what they are trying to do, I guess
my question to you is what don't you understand about their
explanations?

>> > > I haven't looked at it closely enough yet, but that may be a concern
>> > > for users which restrict/subdivide root using a LSM ... although it is
>> > > possible that the LSM policy could help here.  I'm thinking aloud a bit right
>> > > now, but for SELinux the netlink controls aren't very granular and sysfs can
>> > > be tricky so I can't say for certain about blocking fake events from userspace
>> > > using LSMs/SELinux.
>> >
>> > uevents are not tied into LSMs from what I can tell, so I don't
>> > understand wht you are talking about here, sorry.
>>
>> Perhaps I'm mistaken, but uevents are sent to userspace via netlink which
>> does have LSM controls.  There also appears to be a file I/O mechanism via
>> sysfs which also has LSM controls.
>
> And do any of them look at uevents through these mechanisms?
>
> I doubt they care...

Not presently, but if they are tasked with preserving the integrity of
the audit events then they would care.  However, as I typed above,
this isn't something worth worrying about right now and is likely just
a distraction.

-- 
paul moore
www.paul-moore.com

[toc] | [prev] | [next] | [standalone]

#1370915

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.

[toc] | [prev] | [next] | [standalone]

#1370933

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

[toc] | [prev] | [next] | [standalone]

#1371107

That is a good question, maybe I've been lucky in the devices that I have
been testing with.  Most of them seem to be ascii, my assumption was that
shouldn't be a problem.  The same encoding   function used by the path
audit_log_d_path, definitely audits UTF8 named files:

# ausearch -i -f /tmp/test/권성주.txt

type=PATH msg=audit(04/04/16 21:05:00.521:1638) : item=0 name=/tmp/권성주.txt
inode=627534 dev=fd:00 mode=file,664 ouid=wmealing ogid=wmealing rdev=00:00
obj=unconfined_u:object_r:user_tmp_t:s0 objtype=NORMAL

# ausearch -f  /tmp/test/권성주.txt

type=PATH msg=audit(1459818300.521:1638): item=0
name=2F746D702FEAB68CEC84B1ECA3BC2E747874 inode=627534 dev=fd:00
mode=0100664 ouid=1000 ogid=1000 rdev=00:00
obj=unconfined_u:object_r:user_tmp_t:s0 objtype=NORMAL

Thanks,

Wade Mealing.

On Tue, Apr 5, 2016 at 11:51 AM, Wade Mealing <wmealing@redhat.com> wrote:
> That is a good question, maybe I've been lucky in the devices that I have
> been testing with.  Most of them seem to be ascii, my assumption was that
> shouldn't be a problem.  The same encoding   function used by the path
> audit_log_d_path, definitely audits UTF8 named files:
>
> # ausearch -i -f /tmp/test/권성주.txt
>
> type=PATH msg=audit(04/04/16 21:05:00.521:1638) : item=0 name=/tmp/권성주.txt
> inode=627534 dev=fd:00 mode=file,664 ouid=wmealing ogid=wmealing rdev=00:00
> obj=unconfined_u:object_r:user_tmp_t:s0 objtype=NORMAL
>
> # ausearch -f  /tmp/test/권성주.txt
>
> type=PATH msg=audit(1459818300.521:1638): item=0
> name=2F746D702FEAB68CEC84B1ECA3BC2E747874 inode=627534 dev=fd:00
> mode=0100664 ouid=1000 ogid=1000 rdev=00:00
> obj=unconfined_u:object_r:user_tmp_t:s0 objtype=NORMAL
>
> Thanks,
>
> Wade Mealing.
>
> On Tue, Apr 5, 2016 at 7:54 AM, Greg KH <greg@kroah.com> wrote:
>>
>> On Mon, Apr 04, 2016 at 05:37:01PM -0400, Steve Grubb wrote:
>> > On Monday, April 04, 2016 12:02:42 AM wmealing wrote:
>> > > I'm looking to create an audit trail for when devices are added or
>> > > removed
>> > > from the system.
>> > >
>> > > The audit subsystem is a logging subsystem in kernel space that can be
>> > > used to create advanced filters on generated events.  It has partnered
>> > > userspace utilities ausearch, auditd, aureport, auditctl which work
>> > > exclusively on audit records.
>> > >
>> > > These tools are able to set filters to "trigger" on specific in-kernel
>> > > events specified by privileged users.  While the userspace tools can
>> > > create
>> > > audit events these are not able to be handled intelligently
>> > > (decoded,filtered or ignored) as kernel generated audit events are.
>> > >
>> > > I have this working at the moment with the USB subsystem (as an
>> > > example).
>> > > Its been suggested that I use systemd-udev however this means that the
>> > > audit
>> > > tools (ausearch) will not be able to index these records.
>> > >
>> > > Here is an example of picking out the AUDIT_DEVICE record type for
>> > > example.
>> > >
>> > > > # ausearch -l -i -ts today -m AUDIT_DEVICE
>> > > > ----
>> > > > type=AUDIT_DEVICE msg=audit(31/03/16 16:37:15.642:2) : action=add
>> > > > manufacturer=Linux 4.4.0-ktest ehci_hcd product=EHCI Host Controller
>> > > > serial=0000:00:06.7 major=189 minor=0 bus="usb"
>> >
>> > About this event's format...we can't have any spaces in the value side
>> > of the
>> > name=value fields unless its encoded as an untrusted string. You can
>> > replace
>> > spaces with an underscore or dash for readability. So, manufacturer and
>> > product would need this treatment.
>>
>> What is the character encoding that audit messages can accept?  Does it
>> match up with the character encoding that USB strings are in?
>>
>> thanks,
>>
>> greg k-h
>
>

[toc] | [prev] | [next] | [standalone]

#1371143

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?

[toc] | [prev] | [next] | [standalone]

#1371144

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

[toc] | [prev] | [next] | [standalone]

#1370936

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.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | linux.kernel

csiph-web