linux-kernel - Re: [RFC] Create an audit record of USB specific details

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 5 Apr 2016 10:50:53 -0400
From:	Paul Moore <paul@...l-moore.com>
To:	Greg KH <gregkh@...uxfoundation.org>
Cc:	linux-audit@...hat.com, wmealing <wmealing@...hat.com>,
	linux-kernel@...r.kernel.org, linux-usb@...r.kernel.org
Subject: Re: [RFC] Create an audit record of USB specific details

On Mon, Apr 4, 2016 at 11:39 PM, Greg KH <gregkh@...uxfoundation.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@...uxfoundation.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@...hat.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