On April 4, 2016 6:17:23 PM Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxx>
> >
> > 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
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
