Received: by 2002:ac0:a581:0:0:0:0:0 with SMTP id m1-v6csp5302252imm; Tue, 26 Jun 2018 09:01:42 -0700 (PDT) X-Google-Smtp-Source: ADUXVKKclk1+jniJ3T+pIRYSbdDZ+kDFBcFGwAC1Ks8S620+v7sZHrveykMUtoLOrVWBYJ3kyvfv X-Received: by 2002:a17:902:6ac7:: with SMTP id i7-v6mr2316498plt.288.1530028901957; Tue, 26 Jun 2018 09:01:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1530028901; cv=none; d=google.com; s=arc-20160816; b=IrUwmnQoe2PJAN7MsC0vnLGnEsWreUp6fo7fQPRGq0Zm7VHtZzDKeFQP+BEWmRUyDs mCnVS+pqw1lrwJSPQaF04WxJYW8faU6tIuPkC2D6A2YoGaQI40NV3+lnqMdRtbkUsf00 cL3uQG2fzliigkWlSLz3HJPMQiin8aM2j0nlqv3RTEJ2G7HF+L00hXf80XvJIg8cSOZd yMcVv0wpVoQvtfnLVffWLfNRnNF3Hcff89Vy3tpn6IPlM0BuoKHMPK5wh8Mf5J1uvQW3 qK7YwmDZwWXh+ZLo8/4xR5MsQe/dH5Ggic54AECxRLFU3+uODirMq4Q7Ks7WNimkhYfT zzFw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature :arc-authentication-results; bh=teZOA1RN95vYeiZEwputYpyJISmOqXt1qymNUyGBd7M=; b=dk8+ZIm0+FjkR+lkNl04ad0/mc6Ddrbg+8d8XJ5lnuFz080DwQiXGwM+Csw3LV6SvM bBLuKe9MMJLLgcDUr5MctixyFg6yaP168fclhkXfz7IPNw3tIWgAKih/jrf5p0I2Duqg BLwKcnZX6o9T3jb2f7H4WxH2LjVR3JbfS8oiRQrZL72k6fG4jBdIE45tkGEHO/n+shtY +miII/NhH0FoDUiKTSvAfJWLpO91ipR8PU7czCT7VKsGzZhzv+4cDEk08zdvlhFrF9ua B1Ugx7WBIVKZxmecT69onk0nILfTUZOQmxPzgtb/EbBGhpn0EBnKeKX8KmkorQNdlh6r NrIQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=Sf7cmp+5; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 31-v6si1906763plc.173.2018.06.26.09.01.27; Tue, 26 Jun 2018 09:01:41 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=Sf7cmp+5; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965815AbeFZOG7 (ORCPT + 99 others); Tue, 26 Jun 2018 10:06:59 -0400 Received: from mail-oi0-f65.google.com ([209.85.218.65]:42597 "EHLO mail-oi0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965260AbeFZOG6 (ORCPT ); Tue, 26 Jun 2018 10:06:58 -0400 Received: by mail-oi0-f65.google.com with SMTP id n84-v6so8491350oib.9 for ; Tue, 26 Jun 2018 07:06:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=teZOA1RN95vYeiZEwputYpyJISmOqXt1qymNUyGBd7M=; b=Sf7cmp+5w3PJISMLkP1k+69npthtwUASlJCM+yCvSXXMAf425GUdQ5D9LqhaD4T7iM mBiAqQ71drnDteC5sYlVC2ZW/Z7YGc/75XoymoF8cYQMjsEnOa8QmfEIVGvEzVkTUtd+ 7dkqi2xbzV8zJmAXaV7aXi93NmM5iGbeMnNliLKJ+sisejplKtRx/uCrYRPbBvZNo/8L Y/71hrUtDvkn79Gbp5p6ra3lC7Ddm2ygvxBGKgeQzBsCy6hXquo36d3UuJzkXMGA4jKp VHPwIqMcdpBLIDrFj+0YwqpwqBz72fhStcl+RCPPXcF1XGGS8Pr2bVgJTbsbaU0eMNuP +5fw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=teZOA1RN95vYeiZEwputYpyJISmOqXt1qymNUyGBd7M=; b=X4tBdA0sBKB+MMmOG51OUREKXb1EMobk88IUI7f7TrsbFV6iA6AT8vG6RE0h94YEwb DA8misKxEK8DzdJ8HZvCfSo9vloh31bArQR0AyyJD9tfucQOxmRdyfPWqSYFPGydK5oX xHio0UtwfCxnBtC7fYUdFyxKweLlbUTtOBbLjnUyeSB4JyCQW3EFvlJ0/BHOQ1AtGuKR /sTQjnV/y8ML7TjaCKO97trpYM8iH00Uh4LClUvs+6TfAK9Rli7RN0tSzCSnIAA3CHXn 73XLpuyLMLUi7VGBe/2hdOjOsQXXXxsJOR5fYU55S03RSJL+OsyTnH8LZhffX5mAX/xN ZKCg== X-Gm-Message-State: APt69E3QodJpU5Nl/1Ymq+fnv721EWXIVMcxCJesTTeTghqe72lu//+Q 9mqojIF8D0t1fzM3arTCurqLxiWXzX7SEJmJjFmDVw== X-Received: by 2002:aca:5bd5:: with SMTP id p204-v6mr980566oib.91.1530022017344; Tue, 26 Jun 2018 07:06:57 -0700 (PDT) MIME-Version: 1.0 References: <20180625163419.216578-1-jannh@google.com> <20180626130757.GA10042@gmail.com> In-Reply-To: <20180626130757.GA10042@gmail.com> From: Jann Horn Date: Tue, 26 Jun 2018 16:06:45 +0200 Message-ID: Subject: Re: [PATCH] userns: move user access out of the mutex To: christian.brauner@canonical.com Cc: "Eric W. Biederman" , kernel list , security@kernel.org, Andy Lutomirski , Kees Cook , "Serge E. Hallyn" Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jun 26, 2018 at 3:08 PM Christian Brauner wrote: > > On Mon, Jun 25, 2018 at 06:34:19PM +0200, Jann Horn wrote: > > The old code would hold the userns_state_mutex indefinitely if > > memdup_user_nul stalled due to e.g. a userfault region. Prevent that by > > moving the memdup_user_nul in front of the mutex_lock(). > > > > Note: This changes the error precedence of invalid buf/count/*ppos vs > > map already written / capabilities missing. > > > > Fixes: 22d917d80e84 ("userns: Rework the user_namespace adding uid/gid...") > > Cc: stable@vger.kernel.org > > Signed-off-by: Jann Horn > > --- > > kernel/user_namespace.c | 24 ++++++++++-------------- > > 1 file changed, 10 insertions(+), 14 deletions(-) > > > > diff --git a/kernel/user_namespace.c b/kernel/user_namespace.c > > index c3d7583fcd21..e5222b5fb4fe 100644 > > --- a/kernel/user_namespace.c > > +++ b/kernel/user_namespace.c > > @@ -859,7 +859,16 @@ static ssize_t map_write(struct file *file, const char __user *buf, > > unsigned idx; > > struct uid_gid_extent extent; > > char *kbuf = NULL, *pos, *next_line; > > - ssize_t ret = -EINVAL; > > + ssize_t ret; > > + > > + /* Only allow < page size writes at the beginning of the file */ > > + if ((*ppos != 0) || (count >= PAGE_SIZE)) > > + return -EINVAL; > > + > > + /* Slurp in the user data */ > > + kbuf = memdup_user_nul(buf, count); > > + if (IS_ERR(kbuf)) > > + return PTR_ERR(kbuf); > > I'm not opposed to this but what is annoying is the changed error > reporting you pointed out. It seems conceptually way cleaner if missing > permissions are reported before more specific internal errors. > > The question I have is how bad it would be if memdup_user_nul() stalled > and if you see any issues security wise. Given that the mutex is only > taken on operations that are mostly performed when creating or setting > up a new user namespace > > map_write() > create_user_ns() > proc_setgroups_write() > userns_may_setgroups() > > and not when actually interacting with it it seems the worst that > happens is that creation of new user namespaces is not possible anymore. > That shouldn't have any effect on the host though which I would see as a > real issue. But I might be missing context. :) userns_may_setgroups() is involved in sys_setgroups() via may_setgroups(), so if one thread is blocking the userns_state_mutex, nobody can log in anymore. > > /* > > * The userns_state_mutex serializes all writes to any given map. > > @@ -895,19 +904,6 @@ static ssize_t map_write(struct file *file, const char __user *buf, > > if (cap_valid(cap_setid) && !file_ns_capable(file, ns, CAP_SYS_ADMIN)) > > goto out; > > > > - /* Only allow < page size writes at the beginning of the file */ > > - ret = -EINVAL; > > - if ((*ppos != 0) || (count >= PAGE_SIZE)) > > - goto out; > > - > > - /* Slurp in the user data */ > > - kbuf = memdup_user_nul(buf, count); > > - if (IS_ERR(kbuf)) { > > - ret = PTR_ERR(kbuf); > > - kbuf = NULL; > > - goto out; > > - } > > - > > /* Parse the user data */ > > ret = -EINVAL; > > pos = kbuf; > > -- > > 2.18.0.rc2.346.g013aa6912e-goog > >