linux-kernel - Re: [PATCH net-next 2/2 v5] netns: restrict uevents

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAKdAkRT98DmxCHPL+1+COinSEDU0_87GMDL6ZiQEiBJSd286yw@mail.gmail.com>
Date:   Sun, 16 Jun 2019 10:14:32 -0700
From:   Dmitry Torokhov <dmitry.torokhov@...il.com>
To:     Christian Brauner <christian.brauner@...onical.com>
Cc:     "Eric W. Biederman" <ebiederm@...ssion.com>,
        "David S. Miller" <davem@...emloft.net>,
        netdev <netdev@...r.kernel.org>,
        lkml <linux-kernel@...r.kernel.org>, avagin@...tuozzo.com,
        ktkhai@...tuozzo.com, "Serge E. Hallyn" <serge@...lyn.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: Re: [PATCH net-next 2/2 v5] netns: restrict uevents

Hi Christian,

On Sun, Jun 16, 2019 at 9:50 AM Christian Brauner
<christian.brauner@...onical.com> wrote:
>
> Hey Dmitry,
>
> Crostini on ChromeOS is making heavy use of this patchset and of LXD. So
> reverting this almost 1.5 years after the fact will regress all of
> Google's ChromeOS Crostini users, and all LXD/LXC users.
>
> LXD and Crostini by using LXD (through Concierge/Tremplin etc. [2]) are
> using this whole series e.g. when hotplugging usb devices into the
> container.
>
> When a usb hotplug happens, LXD will receive the relevant uevent and
> will forward it to the container. Any process listening on a uevent
> socket inside the container will now be able to see it.
>
> Now, to talk briefly about solutions:
> From what I gather from talking to the ChromeOS guys and from your
> ChromeOS bugtracker and recent patchsets to ARC you are moving your
> Android workloads into Crostini? So like Eric said this seems like a new
> feature you're implementing.

No, I am talking about ARC, not Crostini here.

>
> If you need to be able to listen to uevents inside of a user namespace
> and plan on using Crostini going forward then you can have Crostini
> forward battery uevents to the container. The logic for doing this can
> be found in the LXD codebase (cf. [3]). It's pretty simple. If you want
> to go this route I'm happy to guide you. :)
> Note, both options are a version of what Eric suggested in his last
> paragraph!
>
> What astonishes me is that healthd couldn't have possibly received
> battery uevents for a long time even if Android already was run in user
> namespaces prior to the new feature you're working on and the healthd I
> see in master is not even using uevents anymore (cf. [8]) but rather is
> using sysfs it seems. :)
> Before that healthd was using (cf. [7])
>
> uevent_kernel_multicast_recv()
> |
> -> uevent_kernel_multicast_uid_recv
>
> the latter containing the check
>
> if (cred->uid != 0) {
>     /* ignoring netlink message from non-root user */
>     goto out;
> }
>
> Before my patchset here the uevents sent out came with cred->uid == INVALID_UID
> and so healthd never received those events until very recently.

I see. OK, let me try digging into this to figure out what exactly changed.

Thanks.

-- 
Dmitry