From: Casey Schaufler <firstname.lastname@example.org> To: Andy Lutomirski <email@example.com>, David Howells <firstname.lastname@example.org> Cc: Al Viro <email@example.com>, firstname.lastname@example.org, Linux FS Devel <email@example.com>, Linux API <firstname.lastname@example.org>, email@example.com, firstname.lastname@example.org, LSM List <email@example.com>, LKML <firstname.lastname@example.org>, email@example.com Subject: Re: [RFC][PATCH 0/8] Mount, FS, Block and Keyrings notifications [ver #2] Date: Tue, 4 Jun 2019 13:31:37 -0700 Message-ID: <firstname.lastname@example.org> (raw) In-Reply-To: <CALCETrWzDR=Ap8NQ5-YrVhXCEBgr+hwpjw9fBn0m2NkZzZ7XLQ@mail.gmail.com> n 6/4/2019 10:43 AM, Andy Lutomirski wrote: > On Tue, Jun 4, 2019 at 9:35 AM David Howells <email@example.com> wrote: >> >> Hi Al, >> >> Here's a set of patches to add a general variable-length notification queue >> concept and to add sources of events for: > I asked before and didn't see a response, so I'll ask again. Why are > you paying any attention at all to the creds that generate an event? > It seems like the resulting security model will be vary hard to > understand and probably buggy. Can't you define a sensible model in > which only the listener creds matter? We've spent the last 18 months reeling from the implications of what can happen when one process has the ability to snoop on another. Introducing yet another mechanism that is trivial to exploit is a very bad idea. I will try to explain the problem once again. If process A sends a signal (writes information) to process B the kernel checks that either process A has the same UID as process B or that process A has privilege to override that policy. Process B is passive in this access control decision, while process A is active. In the event delivery case, process A does something (e.g. modifies a keyring) that generates an event, which is then sent to process B's event buffer. Again, A is active and B is passive. Process A must have write access (defined by some policy) to process B's event buffer. To implement such a policy requires A's credential, and some information about the object (passive entity) to which the event is being delivered. You can't just use the credential from Process B because it is not the active entity, it is the passive entity. > >> LSM support is included: >> >> (1) The creds of the process that did the fput() that reduced the refcount >> to zero are cached in the file struct. >> >> (2) __fput() overrides the current creds with the creds from (1) whilst >> doing the cleanup, thereby making sure that the creds seen by the >> destruction notification generated by mntput() appears to come from >> the last fputter. > That looks like duct tape that is, at best, likely to be very buggy. > >> (3) security_post_notification() is called for each queue that we might >> want to post a notification into, thereby allowing the LSM to prevent >> covert communications. > This seems like the wrong approach. If an LSM wants to prevent covert > communication from, say, mount actions, then it shouldn't allow the > watch to be set up in the first place.
next prev parent reply index Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-06-04 16:34 David Howells 2019-06-04 16:35 ` [PATCH 1/8] security: Override creds in __fput() with last fputter's creds " David Howells 2019-06-04 18:15 ` Andy Lutomirski 2019-06-04 16:35 ` [PATCH 2/8] General notification queue with user mmap()'able ring buffer " David Howells 2019-06-04 16:35 ` [PATCH 3/8] keys: Add a notification facility " David Howells 2019-06-04 16:35 ` [PATCH 4/8] vfs: Add a mount-notification " David Howells 2019-06-04 16:35 ` [PATCH 5/8] vfs: Add superblock notifications " David Howells 2019-06-04 16:36 ` [PATCH 6/8] fsinfo: Export superblock notification counter " David Howells 2019-06-04 16:36 ` [PATCH 7/8] block: Add block layer notifications " David Howells 2019-06-04 16:36 ` [PATCH 8/8] Add sample notification program " David Howells 2019-06-04 17:43 ` [RFC][PATCH 0/8] Mount, FS, Block and Keyrings notifications " Andy Lutomirski 2019-06-04 20:31 ` Casey Schaufler [this message] 2019-06-04 21:05 ` Andy Lutomirski 2019-06-04 22:03 ` Casey Schaufler 2019-06-05 8:41 ` David Howells 2019-06-05 14:50 ` Casey Schaufler 2019-06-05 16:04 ` Andy Lutomirski 2019-06-05 17:01 ` Casey Schaufler 2019-06-05 17:47 ` Andy Lutomirski 2019-06-05 18:12 ` Casey Schaufler 2019-06-05 18:25 ` Stephen Smalley 2019-06-05 19:28 ` Greg KH 2019-06-05 21:01 ` Stephen Smalley 2019-06-05 16:56 ` Rational model for UID based controls David Howells 2019-06-05 17:40 ` Casey Schaufler 2019-06-05 21:06 ` David Howells 2019-06-05 17:21 ` [RFC][PATCH 0/8] Mount, FS, Block and Keyrings notifications [ver #2] David Howells 2019-06-04 20:39 ` David Howells 2019-06-04 20:57 ` Andy Lutomirski [not found] ` <CAB9W1A0AgMYOwGx9c-TmAt=1O6Bjsr2P3Nhd=2+QV39dgw0CrA@mail.gmail.com> 2019-06-05 4:19 ` Andy Lutomirski 2019-06-05 13:47 ` Stephen Smalley 2019-06-04 21:11 ` Casey Schaufler
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 \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ /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
LKML Archive on lore.kernel.org Archives are clonable: git clone --mirror https://lore.kernel.org/lkml/0 lkml/git/0.git git clone --mirror https://lore.kernel.org/lkml/1 lkml/git/1.git git clone --mirror https://lore.kernel.org/lkml/2 lkml/git/2.git git clone --mirror https://lore.kernel.org/lkml/3 lkml/git/3.git git clone --mirror https://lore.kernel.org/lkml/4 lkml/git/4.git git clone --mirror https://lore.kernel.org/lkml/5 lkml/git/5.git git clone --mirror https://lore.kernel.org/lkml/6 lkml/git/6.git git clone --mirror https://lore.kernel.org/lkml/7 lkml/git/7.git git clone --mirror https://lore.kernel.org/lkml/8 lkml/git/8.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 lkml lkml/ https://lore.kernel.org/lkml \ firstname.lastname@example.org public-inbox-index lkml Example config snippet for mirrors Newsgroup available over NNTP: nntp://nntp.lore.kernel.org/org.kernel.vger.linux-kernel AGPL code for this site: git clone https://public-inbox.org/public-inbox.git