Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932436AbcDDWR1 (ORCPT ); Mon, 4 Apr 2016 18:17:27 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:35847 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752289AbcDDWRY (ORCPT ); Mon, 4 Apr 2016 18:17:24 -0400 Date: Mon, 4 Apr 2016 14:50:41 -0700 From: Greg KH To: Paul Moore Cc: linux-audit@redhat.com, wmealing , linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org Subject: Re: [RFC] Create an audit record of USB specific details Message-ID: <20160404215041.GB26580@kroah.com> References: <1459742562-22803-1-git-send-email-wmail@redhat.com> <20160404125626.GB6197@kroah.com> <1712342.QWWAT5XPGs@sifl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1712342.QWWAT5XPGs@sifl> User-Agent: Mutt/1.6.0 (2016-04-01) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1888 Lines: 43 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 > > > > > > 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