From: Greg KH <gregkh@linuxfoundation.org>
To: Yongji Xie <xieyongji@bytedance.com>
Cc: devel@driverdev.osuosl.org, tkjos@android.com,
Kees Cook <keescook@chromium.org>,
maco@android.com, Jason Wang <jasowang@redhat.com>,
joel@joelfernandes.org, Christoph Hellwig <hch@infradead.org>,
Hridya Valsaraju <hridya@google.com>,
arve@android.com, viro@zeniv.linux.org.uk,
Sargun Dhillon <sargun@sargun.me>,
linux-fsdevel@vger.kernel.org,
Christian Brauner <christian.brauner@ubuntu.com>,
Suren Baghdasaryan <surenb@google.com>
Subject: Re: Re: Re: Re: [PATCH 2/2] binder: Use receive_fd() to receive file from another process
Date: Thu, 1 Apr 2021 16:09:57 +0200 [thread overview]
Message-ID: <YGXUNfsExs6tZD0c@kroah.com> (raw)
In-Reply-To: <CACycT3vNaDg5twEpKtnZTjbyD=0FhZKJLzH+uBNQuyCmxFaeww@mail.gmail.com>
On Thu, Apr 01, 2021 at 08:28:02PM +0800, Yongji Xie wrote:
> On Thu, Apr 1, 2021 at 7:33 PM Greg KH <gregkh@linuxfoundation.org> wrote:
> >
> > On Thu, Apr 01, 2021 at 07:29:45PM +0800, Yongji Xie wrote:
> > > On Thu, Apr 1, 2021 at 6:42 PM Greg KH <gregkh@linuxfoundation.org> wrote:
> > > >
> > > > On Thu, Apr 01, 2021 at 06:12:51PM +0800, Yongji Xie wrote:
> > > > > On Thu, Apr 1, 2021 at 5:54 PM Greg KH <gregkh@linuxfoundation.org> wrote:
> > > > > >
> > > > > > On Thu, Apr 01, 2021 at 05:09:32PM +0800, Xie Yongji wrote:
> > > > > > > Use receive_fd() to receive file from another process instead of
> > > > > > > combination of get_unused_fd_flags() and fd_install(). This simplifies
> > > > > > > the logic and also makes sure we don't miss any security stuff.
> > > > > >
> > > > > > But no logic is simplified here, and nothing is "missed", so I do not
> > > > > > understand this change at all.
> > > > > >
> > > > >
> > > > > I noticed that we have security_binder_transfer_file() when we
> > > > > transfer some fds. I'm not sure whether we need something like
> > > > > security_file_receive() here?
> > > >
> > > > Why would you? And where is "here"?
> > > >
> > > > still confused,
> > > >
> > >
> > > I mean do we need to go through the file_receive seccomp notifier when
> > > we receive fd (use get_unused_fd_flags() + fd_install now) from
> > > another process in binder_apply_fd_fixups().
> >
> > Why? this is internal things, why does seccomp come into play here?
> >
>
> We already have security_binder_transfer_file() to control the sender
> process. So for the receiver process, do we need the seccomp too? Or
> do I miss something here?
I do not know, is this something that is a requirement that seccomp
handle all filesystem handles sent to a process? I do not know the
seccomp "guarantee" that well, sorry.
greg k-h
next prev parent reply other threads:[~2021-04-01 17:52 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-01 9:09 [PATCH 0/2] Export receive_fd() to modules and do some cleanups Xie Yongji
2021-04-01 9:09 ` [PATCH 1/2] file: Export receive_fd() to modules Xie Yongji
2021-04-01 9:52 ` Greg KH
2021-04-01 10:24 ` Yongji Xie
2021-04-01 9:09 ` [PATCH 2/2] binder: Use receive_fd() to receive file from another process Xie Yongji
2021-04-01 9:54 ` Greg KH
2021-04-01 10:12 ` Yongji Xie
2021-04-01 10:42 ` Greg KH
2021-04-01 11:29 ` Yongji Xie
2021-04-01 11:33 ` Greg KH
2021-04-01 12:28 ` Yongji Xie
2021-04-01 14:09 ` Greg KH [this message]
2021-04-02 9:12 ` Kees Cook
2021-04-01 10:40 ` Christian Brauner
2021-04-01 11:11 ` Yongji Xie
2021-04-16 5:19 ` Al Viro
2021-04-16 5:55 ` Al Viro
2021-04-16 13:42 ` Christian Brauner
2021-04-16 14:09 ` Al Viro
2021-04-16 15:13 ` Christian Brauner
2021-04-16 15:35 ` Al Viro
2021-04-16 15:58 ` Christian Brauner
2021-04-16 16:00 ` Christian Brauner
2021-04-16 17:00 ` Al Viro
2021-04-16 17:30 ` Al Viro
2021-04-17 1:30 ` Al Viro
2021-04-01 9:53 ` [PATCH 0/2] Export receive_fd() to modules and do some cleanups Greg KH
2021-04-01 10:00 ` Yongji Xie
2021-04-01 10:20 ` Christian Brauner
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=YGXUNfsExs6tZD0c@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=arve@android.com \
--cc=christian.brauner@ubuntu.com \
--cc=devel@driverdev.osuosl.org \
--cc=hch@infradead.org \
--cc=hridya@google.com \
--cc=jasowang@redhat.com \
--cc=joel@joelfernandes.org \
--cc=keescook@chromium.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=maco@android.com \
--cc=sargun@sargun.me \
--cc=surenb@google.com \
--cc=tkjos@android.com \
--cc=viro@zeniv.linux.org.uk \
--cc=xieyongji@bytedance.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.