linux-kernel - RE: [PATCH V4] binder: ipc namespace support for android binder

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>] [day] [month] [year] [list]

Date:   Tue, 20 Nov 2018 03:56:45 +0000
From:   chouryzhou(周威) <chouryzhou@...cent.com>
To:     Christian Brauner <christian@...uner.io>,
        Todd Kjos <tkjos@...gle.com>
CC:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        "akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
        Arve Hjønnevåg <arve@...roid.com>,
        Todd Kjos <tkjos@...roid.com>,
        "dave@...olabs.net" <dave@...olabs.net>,
        "open list:ANDROID DRIVERS" <devel@...verdev.osuosl.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH V4] binder: ipc namespace support for android binder

> On Fri, Nov 16, 2018 at 11:19:41AM -0800, Todd Kjos wrote:
> > On Thu, Nov 15, 2018 at 2:54 PM gregkh@...uxfoundation.org
> > <gregkh@...uxfoundation.org> wrote:
> > ...
> > >
> > > A number of us have talked about this in the plumbers Android track, and
> > > a different proposal for how to solve this has been made that should be
> > > much more resiliant.  So I will drop this patch from my queue and wait
> > > for the patches based on the discussions we had there.
> > >
> > > I think there's some notes/slides on the discussion online somewhere,
> > > but it hasn't been published as the conference is still happening,
> > > otherwise I would link to it here...
> >
> > Here is a link to the session where you can look at the slides [1].
> > There was consensus that "binderfs" (slide 5) was the most promising
> > -- but would be behind a config option to provide backwards
> > compatibility for non-container use-cases.
> >
> > The etherpad notes are at [2] (look at "Dynamically Allocated Binder
> > Devices" section)
> >
> > Christian Brauner will be sending out more details.
> 
> Ok, sorry for the delay I got caught up in other work.
> 
> The idea is to implement binderfs which I'm starting to work on.
> binderfs will be a separate pseudo-filesystem that will be mountable
> per-ipc namespace.
> This has the advantage that the ipc namespace is attached to the
> superblock of the mount and can be easily retrieved by the binder
> driver. It also implies that - in contrast to the proposed patch here -
> an open() on a given binder device will not be able to change the ipc
> namespace of said devices. The obvious corollary is that you can
> bind-mount binder devices or the whole binderfs mount between different
> ipc namespaces and given the right permissions (CAP_IPC_OWNER in the
> owning userns of the ipcns) can see services on the host which is
> something that people wanted to be able to do.
> Additionally, each binderfs mount will come with a binder-control
> device. This device is functionally similar to loop-control and will
> allow for dynamic allocation (and possibly deallocation) of binder
> devices. With this we can remove the restriction to hard-code the number
> of binder devices at compile time.
> Backwards compatibility can either be guaranteed by hiding binderfs
> behind a compile flag or by special-casing the inital binderfs mount to
> pre-create the standard binder devices. The jury is still out on this.
> 
> Christian
> 

Since you are working on this, I will withdraw this patch. We will evaluate 
whether to your solution in our environment after you implement it.