Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756419AbcDDViE (ORCPT ); Mon, 4 Apr 2016 17:38:04 -0400 Received: from mail-qg0-f66.google.com ([209.85.192.66]:36094 "EHLO mail-qg0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754311AbcDDViB (ORCPT ); Mon, 4 Apr 2016 17:38:01 -0400 From: Paul Moore To: linux-audit@redhat.com, Greg KH , wmealing Cc: linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org Subject: Re: [RFC] Create an audit record of USB specific details Date: Mon, 04 Apr 2016 17:37:58 -0400 Message-ID: <1712342.QWWAT5XPGs@sifl> User-Agent: KMail/4.14.10 (Linux/4.4.5-gentoo; KDE/4.14.17; x86_64; ; ) In-Reply-To: <20160404125626.GB6197@kroah.com> References: <1459742562-22803-1-git-send-email-wmail@redhat.com> <20160404125626.GB6197@kroah.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1520 Lines: 32 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. 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