netdev - Re: [PATCH v5 01/11] file: Export __receive

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: <20210315144444.bgtllddee7s55lfx@gmail.com>
Date:   Mon, 15 Mar 2021 15:44:44 +0100
From:   Christian Brauner <christian.brauner@...onical.com>
To:     Yongji Xie <xieyongji@...edance.com>
Cc:     Christoph Hellwig <hch@...radead.org>,
        "Michael S. Tsirkin" <mst@...hat.com>,
        Jason Wang <jasowang@...hat.com>,
        Stefan Hajnoczi <stefanha@...hat.com>,
        Stefano Garzarella <sgarzare@...hat.com>,
        Parav Pandit <parav@...dia.com>, Bob Liu <bob.liu@...cle.com>,
        Randy Dunlap <rdunlap@...radead.org>,
        Matthew Wilcox <willy@...radead.org>, viro@...iv.linux.org.uk,
        Jens Axboe <axboe@...nel.dk>, bcrl@...ck.org,
        Jonathan Corbet <corbet@....net>,
        Mika Penttilä <mika.penttila@...tfour.com>,
        Dan Carpenter <dan.carpenter@...cle.com>,
        virtualization@...ts.linux-foundation.org, netdev@...r.kernel.org,
        kvm@...r.kernel.org, linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH v5 01/11] file: Export __receive_fd() to modules

On Mon, Mar 15, 2021 at 05:46:43PM +0800, Yongji Xie wrote:
> On Mon, Mar 15, 2021 at 5:08 PM Christoph Hellwig <hch@...radead.org> wrote:
> >
> > On Mon, Mar 15, 2021 at 01:37:11PM +0800, Xie Yongji wrote:
> > > Export __receive_fd() so that some modules can use
> > > it to pass file descriptor between processes.
> >
> > I really don't think any non-core code should do that, especilly not
> > modular mere driver code.
> 
> Do you see any issue? Now I think we're able to do that with the help
> of get_unused_fd_flags() and fd_install() in modules. But we may miss
> some security stuff in this way. So I try to export __receive_fd() and
> use it instead.

The __receive_fd() helper was added for core-kernel code only and we
mainly did it for the seccomp notifier (and scm rights). The "__" prefix
was intended to convey that message.
And I agree with Christoph that we should probably keep it that way
since __receive_fd() allows a few operations that no driver should
probably do.
I can see it being kinda ok to export a variant that really only
receives and installs an fd, i.e. if we were to export what's currently
available as an inline helper:

static inline int receive_fd(struct file *file, unsigned int o_flags)

but definitely none of the fd replacement stuff; that shold be
off-limits. The seccomp notifier is the only codepath that should even
think about fd replacement since it's about managing the syscalls of
another task. Drivers swapping out fds doesn't sound like a good idea to
me.

Christian