linux-kernel - Re: What do LSMs *actually* need for checks on notifications?

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]

Message-ID: <17322.1560364615@warthog.procyon.org.uk>
Date:   Wed, 12 Jun 2019 19:36:55 +0100
From:   David Howells <dhowells@...hat.com>
To:     Casey Schaufler <casey@...aufler-ca.com>
Cc:     dhowells@...hat.com, Stephen Smalley <sds@...ho.nsa.gov>,
        Andy Lutomirski <luto@...nel.org>, viro@...iv.linux.org.uk,
        linux-usb@...r.kernel.org, linux-security-module@...r.kernel.org,
        linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: What do LSMs *actually* need for checks on notifications?

Casey Schaufler <casey@...aufler-ca.com> wrote:

> >  (*) Device events (block/usb) don't require any permissions, but currently
> >      only deliver hardware notifications.
> 
> How do you specify what device you want to watch?

It's a general queue.

> Don't you have to access a /dev/something?

Not at the moment.  One problem is that there may not be a /dev/something for
a device (take a bridge for example), and even if it does, the device driver
doesn't necessarily have access to the path.  The messages contain the device
name string as appears in dmesg ("3-7" for a USB device, for example).

I think it would be wise to limit the general queue to hardware events that
either get triggered by someone physically mucking around with the hardware or
device errors, such as bad sectors or links going up and down.

> > You can't find out what watches exist.
> 
> Not even your own?

No.

> > However, it should be noted that (1) is the creds of the buffer owner.
> 
> How are buffers shared? Who besides the buffer creator can use it?

When you open /dev/watch_queue, you get buffers private to that file object; a
second open of the device, even by the same process, will get different
buffers.

The buffers are 'attached' to that file and are accessed by calling mmap() on
the fd; shareability is governed by how shareable the fd and a mapping are
shareable.

> Can you glean information from the watch being deleted?
> I wouldn't think so, and it seems like a one-time event
> from the system, so I don't think an access check would
> be required.

As you say, it's a one-time message per watch.  The object that got deleted
would need to be recreated, rewatched and made available to both parties.

David