Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp3086898pxu; Tue, 8 Dec 2020 03:16:06 -0800 (PST) X-Google-Smtp-Source: ABdhPJwiUbpv9f8OgOM87aZV4CZ2NoFDdz9za5SW3RYueqbYAgMKr+NDWnJS55C/DWLkzYPM0JIY X-Received: by 2002:a05:6402:1646:: with SMTP id s6mr24130168edx.319.1607426166776; Tue, 08 Dec 2020 03:16:06 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1607426166; cv=none; d=google.com; s=arc-20160816; b=QCatvM1OlXWod6QxSpX1JC7rVXHa1VM5TILHJ9kDqI6N22b+impf1YXYFEPAZr39BC i2RD1despHYC//grlbNKGuTm/anIPeDP5GV8A3qW49Pow8oieJY01s9v0SFPH2amhmtY x+lLmeK4rPKkjdNQBseZHLaxSxayzKLJhtlFqlox9Wfqo6dpgxiEfua/cZHjlSTKFmBP dSckbGHbkQjJU0E8YIUhdSSGzAL8wf4qKpYVyBxbflp09uXHDrzSwMMmgH7WhbDXpAz6 uQ94fqhhuHGCAKq29Xg+CV9rdzCKjWJI9dqYAtW0JTsZEA3nG0knzDPRSgZHWQjM0kmG c+AA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=fthot3QpP4vDk7cAw8On/plq+0eEtaEDbWP9YivflwA=; b=glAWgSzncVn+OSY/d+QnSWIVRL9zug6anQb3U1bt4XHHl/Mwt7zURe0nSQ+0I1ju7L /zIIkk9jB+QLLEdFtsiQn3RF0xoUnz2cNrGLiwINWBQh2vGC1DzPwSjx63SAbbsngoKt e4iTLGXizZFRdYAnHbR6elRDcFxxwgFmDqfoiiFpLVJw08ycHiTPYtPvQxTtCqAgTAAM EoS5jMac1AG+Pcw12djuszL8jCvdt8EJT4Mip1FcgzbFBN3ruy/9WOkYurL9IfD4egRr R/kxy5W/FTCNQ1yDNW5dUJxN/KZNs2x7/FoAWamP15jZQxKBoJ8I9qcn1k8yrI3uyzuM Icow== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=e2I4TcXc; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id v4si1206577edi.191.2020.12.08.03.15.43; Tue, 08 Dec 2020 03:16:06 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=e2I4TcXc; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728746AbgLHLMM (ORCPT + 99 others); Tue, 8 Dec 2020 06:12:12 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35304 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726993AbgLHLML (ORCPT ); Tue, 8 Dec 2020 06:12:11 -0500 Received: from mail-il1-x143.google.com (mail-il1-x143.google.com [IPv6:2607:f8b0:4864:20::143]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 57748C061749; Tue, 8 Dec 2020 03:11:31 -0800 (PST) Received: by mail-il1-x143.google.com with SMTP id r17so15106643ilo.11; Tue, 08 Dec 2020 03:11:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=fthot3QpP4vDk7cAw8On/plq+0eEtaEDbWP9YivflwA=; b=e2I4TcXcIwAVJiCOHzGm3G4CERo9gOfYIA+K9xvwroNmhK0ZMCY8xbTs5kPKmms9se NrBBiP4fYKl3yG20XAGIemzw9Ym/GWMU1QgXUsI5qlmzsdA8CwJ9DNQhxYuSXvjaDCPl iW5GZlUCi2qcWOvS0BGiHRVyj3wWsEd9ZCB+syW2cttj/XIasb4W8KGv88W4oiFciLWG qXqLdnnlGh8UWfxwEA/8v/d9P5y3/EqEjDd/64k4UrqVl7dbZAm5TAY2IrIJ91QL+og0 kjC/6vKiGF94smt+LGH+gq7BFm4cb3u8PBvdPHUhw1If4hPpRWZPwXurWnwf7Fkm2Hzm mvqA== 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=fthot3QpP4vDk7cAw8On/plq+0eEtaEDbWP9YivflwA=; b=p+UQZPZb3kDBN+cJLrFTAd4HmVEAfIdyj0q0ptf25hgt54ixMMpm7KX1YJ46BvyGQg pgKO+BR0fMwzSZeoauIr1vVinlzOX29FgMVHyOhfTB+OYNYHGAD+VcnehqejsW7tt1ip qTb261kcoqoD4kPywZdoDmXSmGJLDNnE10foLF98jZ+ZVkrUIxQLADynp7G+DhtyG6Pm ofYdVpezTY2DgM0tBEhQAwKoEXW7Lr5OZRbZvdLgSdm3bmLBZL6ZwWDmrU0Tu4fBgnM9 yaNEZWXpVRqH+zv/kUzvXeXbvR/f/hLYQHIfpLiYVR4x2Bdy02q1Jl+VL052gwRANN0Y 5e5g== X-Gm-Message-State: AOAM531kFeLY7U2avyhmJhxnwkJAU49b1pK9Agl6iuR25aTHPJjt0zO0 hp4DpxPayMfKMU3FMnfDZEZoqu/V5YQ26UPd70Q= X-Received: by 2002:a05:6e02:160b:: with SMTP id t11mr26756697ilu.275.1607425890676; Tue, 08 Dec 2020 03:11:30 -0800 (PST) MIME-Version: 1.0 References: <20201207163255.564116-1-mszeredi@redhat.com> <20201207163255.564116-5-mszeredi@redhat.com> In-Reply-To: <20201207163255.564116-5-mszeredi@redhat.com> From: Amir Goldstein Date: Tue, 8 Dec 2020 13:11:19 +0200 Message-ID: Subject: Re: [PATCH v2 04/10] ovl: make ioctl() safe To: Miklos Szeredi Cc: "Eric W . Biederman" , linux-fsdevel , overlayfs , LSM List , linux-kernel , Dmitry Vyukov Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Dec 7, 2020 at 6:36 PM Miklos Szeredi wrote: > > ovl_ioctl_set_flags() does a capability check using flags, but then the > real ioctl double-fetches flags and uses potentially different value. > > The "Check the capability before cred override" comment misleading: user > can skip this check by presenting benign flags first and then overwriting > them to non-benign flags. > > Just remove the cred override for now, hoping this doesn't cause a > regression. > > The proper solution is to create a new setxflags i_op (patches are in the > works). > > Xfstests don't show a regression. > > Reported-by: Dmitry Vyukov > Signed-off-by: Miklos Szeredi Looks reasonable Reviewed-by: Amir Goldstein > --- > fs/overlayfs/file.c | 75 ++------------------------------------------- > 1 file changed, 3 insertions(+), 72 deletions(-) > > diff --git a/fs/overlayfs/file.c b/fs/overlayfs/file.c > index efccb7c1f9bc..3cd1590f2030 100644 > --- a/fs/overlayfs/file.c > +++ b/fs/overlayfs/file.c > @@ -541,46 +541,26 @@ static long ovl_real_ioctl(struct file *file, unsigned int cmd, > unsigned long arg) > { > struct fd real; > - const struct cred *old_cred; > long ret; > > ret = ovl_real_fdget(file, &real); > if (ret) > return ret; > > - old_cred = ovl_override_creds(file_inode(file)->i_sb); > ret = security_file_ioctl(real.file, cmd, arg); > if (!ret) > ret = vfs_ioctl(real.file, cmd, arg); > - revert_creds(old_cred); > > fdput(real); > > return ret; > } > I wonder if we shouldn't leave a comment behind to explain that no override is intentional. I also wonder if "Permission model" sections shouldn't be saying something about ioctl() (current task checks only)? or we just treat this is a breakage of the permission model that needs to be fixed? Thanks, Amir.