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

Date:   Tue, 20 Nov 2018 01:23:49 +0100
From:   Christian Brauner <christian@...uner.io>
To:     Todd Kjos <tkjos@...gle.com>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        akpm@...ux-foundation.org, chouryzhou@...cent.com,
        Arve Hjønnevåg <arve@...roid.com>,
        Todd Kjos <tkjos@...roid.com>, 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

> 
> -Todd
> 
> [1] https://linuxplumbersconf.org/event/2/contributions/222/
> [2] https://etherpad.openstack.org/p/Android
> 
> >
> > thanks,
> >
> > greg k-h