All of lore.kernel.org
 help / color / mirror / Atom feed
From: Miklos Szeredi <mszeredi@redhat.com>
To: Vivek Goyal <vgoyal@redhat.com>
Cc: virtio-fs-list <virtio-fs@redhat.com>,
	"Howells, David" <dhowells@redhat.com>,
	Max Reitz <mreitz@redhat.com>
Subject: Re: [Virtio-fs] Securing file handles
Date: Wed, 17 Mar 2021 16:13:37 +0100	[thread overview]
Message-ID: <CAOssrKdnsRph+a1_qP_z2QT0i4NourtotUovdpV2uDDVKcN7Pw@mail.gmail.com> (raw)
In-Reply-To: <20210317131906.GB324911@redhat.com>

[CC] David Howells.

On Wed, Mar 17, 2021 at 2:19 PM Vivek Goyal <vgoyal@redhat.com> wrote:
>
> On Tue, Mar 16, 2021 at 06:28:24PM +0100, Max Reitz wrote:

> > One thing that also needs to be solved is how to specify a persistent key.
> > I suppose the idea in your patch is to generate a random key for every new
> > process, but we would need a persistent key.  With a service process, it
> > could be configured by the user to use a specific key, or perhaps it has
> > kind of small database and virtiofsd selects its persistent key by a hash of
> > it or some other ID that it has received from the service process.
> >
> > I don’t know how you’d go making the kernel store persistent keys, though.
>
> Is it possible to load persistent key from user space into a keyring
> using keyctl.

Context for David:

We'd like unprivileged open_by_handle_at(2).   One idea is for the
kernel to authenticate file handles (add an authentication header)
using a secret key, so that unprivileged open_by_handle_at() only
works on handles obtained through file_to_handle_at(), and will reject
any maliciously crafted file handles.

So the question is how the authentication keys should be managed.

The unprivileged process must not have access to the key, obviously,
but it should be possible to save the key across restarts.

Any ideas?

Thanks,
Miklos



  reply	other threads:[~2021-03-17 15:13 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-05 16:22 [Virtio-fs] Securing file handles Max Reitz
2021-03-08  9:06 ` Sergio Lopez
2021-03-08 10:52   ` Max Reitz
2021-03-08 14:15     ` Sergio Lopez
2021-03-08 15:01   ` Stefan Hajnoczi
2021-03-08  9:54 ` Miklos Szeredi
2021-03-08 11:29   ` Max Reitz
2021-03-08 12:30     ` Miklos Szeredi
2021-03-08 13:39       ` Max Reitz
2021-03-08 14:50         ` Miklos Szeredi
2021-03-16 17:28           ` Max Reitz
2021-03-17 13:19             ` Vivek Goyal
2021-03-17 15:13               ` Miklos Szeredi [this message]
2021-03-08 22:03   ` Vivek Goyal
2021-03-08 11:44 ` Dr. David Alan Gilbert

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=CAOssrKdnsRph+a1_qP_z2QT0i4NourtotUovdpV2uDDVKcN7Pw@mail.gmail.com \
    --to=mszeredi@redhat.com \
    --cc=dhowells@redhat.com \
    --cc=mreitz@redhat.com \
    --cc=vgoyal@redhat.com \
    --cc=virtio-fs@redhat.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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.