From: Linus Torvalds <torvalds@linux-foundation.org>
To: Ray Strode <rstrode@redhat.com>
Cc: David Howells <dhowells@redhat.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Steven Whitehouse <swhiteho@redhat.com>,
Nicolas Dichtel <nicolas.dichtel@6wind.com>,
raven@themaw.net, keyrings@vger.kernel.org,
linux-usb@vger.kernel.org,
linux-block <linux-block@vger.kernel.org>,
Christian Brauner <christian@brauner.io>,
LSM List <linux-security-module@vger.kernel.org>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
Linux API <linux-api@vger.kernel.org>,
Linux List Kernel Mailing <linux-kernel@vger.kernel.org>,
Al Viro <viro@zeniv.linux.org.uk>,
"Ray, Debarshi" <debarshi.ray@gmail.com>,
Robbie Harwood <rharwood@redhat.com>
Subject: Re: Why add the general notification queue and its sources
Date: Thu, 5 Sep 2019 13:39:00 -0700 [thread overview]
Message-ID: <CAHk-=wjcsxQ8QB_v=cwBQw4pkJg7pp-bBsdWyPivFO_OeF-y+g@mail.gmail.com> (raw)
In-Reply-To: <CAKCoTu7ms_Mr-q08d9XB3uascpzwBa5LF9JTT2aq8uUsoFE8aQ@mail.gmail.com>
On Thu, Sep 5, 2019 at 11:33 AM Ray Strode <rstrode@redhat.com> wrote:
>
> Hi,
>
> On Thu, Sep 5, 2019 at 1:20 PM Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> > You've at least now answered part of the "Why", but you didn't
> > actually answer the whole "another developer" part.
> It's certainly something we've wanted in the GNOME world for a long time:
>
> See for instance
>
> https://bugzilla.redhat.com/show_bug.cgi?id=991110
That is *way* too specific to make for any kind of generic
notification mechanism.
Also, what is the security model here? Open a special character
device, and you get access to random notifications from random
sources?
That makes no sense. Do they have the same security permissions?
USB error reporting is one thing - and has completely different
security rules than some per-user key thing (or system? or namespace?
Or what?)
And why would you do a broken big-key thing in the kernel in the first
place? Why don't you just have a kernel key to indirectly encrypt
using a key and "additional user space data". The kernel should simply
not take care of insane 1MB keys.
Big keys just don't make sense for a kernel. Just use the backing
store THAT YOU HAVE TO HAVE ANYWAY. Introduce some "indirect key"
instead that is used to encrypt and authenticate the backing store.
And mix in /proc/mounts tracking, which has a namespace component and
completely different events and security model (likely "none" - since
you can always read your own /proc/mounts).
So honestly, this all just makes me go "user interfaces are hard, all
the users seem to have *completely* different requirements, and nobody
has apparently really tested this in practice".
Maybe a generic notification mechanism is sensible. But I don't see
how security issues could *possibly* be unified, and some of the
examples given (particularly "track changes to /proc/mounts") seem to
have obviously better alternatives (as in "just support poll() on
it").
All this discussion has convinced me of is that this whole thing is
half-baked and not ready even on a conceptual level.
So as far as I'm concerned, I think I want things like actual
"Tested-by:" lines from actual users, because it's not clear that this
makes sense. Gnome certainly should work as a regular user, if you
need a system daemon for it with root privileges you might as well
just do any notification entirely inside that daemon in user space.
Same goes for /proc/mounts - which as mentioned has a much more
obvious interface for waiting anyway.
User interfaces need a lot of thought and testing. They shouldn't be
ad-hoc "maybe this could work for X, Y and Z" theories.
Linus
next prev parent reply other threads:[~2019-09-05 20:39 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-04 22:15 [PATCH 00/11] Keyrings, Block and USB notifications [ver #8] David Howells
2019-09-04 22:15 ` [PATCH 01/11] uapi: General notification ring definitions " David Howells
2019-09-04 22:16 ` [PATCH 02/11] security: Add hooks to rule on setting a watch " David Howells
2019-09-04 22:16 ` [PATCH 03/11] security: Add a hook for the point of notification insertion " David Howells
2019-09-04 22:16 ` [PATCH 04/11] General notification queue with user mmap()'able ring buffer " David Howells
2019-09-04 22:16 ` [PATCH 05/11] keys: Add a notification facility " David Howells
2019-09-04 22:16 ` [PATCH 06/11] Add a general, global device notification watch list " David Howells
2019-09-04 22:16 ` [PATCH 07/11] block: Add block layer notifications " David Howells
2019-09-04 22:16 ` [PATCH 08/11] usb: Add USB subsystem " David Howells
2019-09-04 22:17 ` [PATCH 09/11] Add sample notification program " David Howells
2019-09-04 22:17 ` [PATCH 10/11] selinux: Implement the watch_key security hook " David Howells
2019-09-04 22:17 ` [PATCH 11/11] smack: Implement the watch_key and post_notification hooks " David Howells
2019-09-04 22:28 ` [PATCH 00/11] Keyrings, Block and USB notifications " Linus Torvalds
2019-09-05 17:01 ` Why add the general notification queue and its sources David Howells
2019-09-05 17:19 ` Linus Torvalds
2019-09-05 18:32 ` Ray Strode
2019-09-05 20:39 ` Linus Torvalds [this message]
2019-09-06 19:32 ` Ray Strode
2019-09-06 19:41 ` Ray Strode
2019-09-06 19:53 ` Robbie Harwood
2019-09-05 21:32 ` David Howells
2019-09-05 22:08 ` Linus Torvalds
2019-09-05 23:18 ` David Howells
2019-09-06 0:07 ` Linus Torvalds
2019-09-06 10:09 ` David Howells
2019-09-06 15:35 ` Linus Torvalds
2019-09-06 15:53 ` Linus Torvalds
2019-09-06 16:12 ` Steven Whitehouse
2019-09-06 17:07 ` Linus Torvalds
2019-09-06 17:14 ` Linus Torvalds
2019-09-06 21:19 ` David Howells
2019-09-06 17:14 ` Andy Lutomirski
2019-09-05 18:37 ` Steven Whitehouse
2019-09-05 18:51 ` Ray Strode
2019-09-05 20:09 ` David Lehman
2019-09-05 18:33 ` Greg Kroah-Hartman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAHk-=wjcsxQ8QB_v=cwBQw4pkJg7pp-bBsdWyPivFO_OeF-y+g@mail.gmail.com' \
--to=torvalds@linux-foundation.org \
--cc=christian@brauner.io \
--cc=debarshi.ray@gmail.com \
--cc=dhowells@redhat.com \
--cc=gregkh@linuxfoundation.org \
--cc=keyrings@vger.kernel.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-block@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=nicolas.dichtel@6wind.com \
--cc=raven@themaw.net \
--cc=rharwood@redhat.com \
--cc=rstrode@redhat.com \
--cc=swhiteho@redhat.com \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).