Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp7564046imm; Tue, 28 Aug 2018 14:35:20 -0700 (PDT) X-Google-Smtp-Source: ANB0Vdb3PXy8q8A8fF+Ml5646wZHHMc845jysXVpd2uZv+tNI9gZvaf53enVff/2uDhOiuNY7HGU X-Received: by 2002:a63:447:: with SMTP id 68-v6mr3133605pge.409.1535492120486; Tue, 28 Aug 2018 14:35:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1535492120; cv=none; d=google.com; s=arc-20160816; b=bv1o32gV6h2lo8kSWoQYjJ0XcxNJqpMdQguxFyZkt10Tz6O6i5S5ZSSnAqqOHmNON3 qD1vDWJUe2rrg2qKgw7BSMdqhLlCh8uRqAiZbgBUoyoW+V4c/CVj0nEz9FY8qciQqUbY r84RA61lQ3WEIvaIwPczVcgArnKVj8T7GI3RdyTxsMEczzMIPnhbNXPK7FmTqEr3Msue C9+80Rpuu03hNo/+q2k+jTcoUJdn88KVtcksXT84DD4UwhGuOL5Pciyhrb3xYpx1qcOV ADY8Lu71wtwmxp0uvN2kP/INzWd7zn0i/XEES3gp94D6nP3k8Jv/n+ULDYJUt58cMSZj dOUg== 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=6uU+1czB0xcCLwe5eg+rEV09bRkW/K/kWC734SPQmAk=; b=b9jOgq8FGMdzEfYyfuk32WtJLEMO6kIE+Pp523P0K4eXWjCX0nNd193Ha5jil9R4Au 39ZDRYmomSHRFu7bcI7VCPzeqf6wa83tTyiDikpENVLcsGV8Bf5I0y9IviKOl06JlQVB +km9q/v8z43zIEw+0NQKGoXuzmmD6sOqvzPvn5zLK2BS/nKFtz4efOa42YccNyHpo968 5mba/c4oIF+qSvvRMm8JxiNb0sjvGgnCRLtQH5Rx5o2YH64DWhmBmnSa22xi2UU/CO5m tC2j81JcjZjwhlZ3Jnijxw3zTwI/9c67HFdm8kZZ+XCNYzVAkaHEzegzFaJY/rjEQXIn oRZg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=HujmMrFi; 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=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id a186-v6si1922547pge.408.2018.08.28.14.35.04; Tue, 28 Aug 2018 14:35:20 -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=@gmail.com header.s=20161025 header.b=HujmMrFi; 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=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727551AbeH2B0f (ORCPT + 99 others); Tue, 28 Aug 2018 21:26:35 -0400 Received: from mail-yb0-f194.google.com ([209.85.213.194]:43018 "EHLO mail-yb0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727144AbeH2B0e (ORCPT ); Tue, 28 Aug 2018 21:26:34 -0400 Received: by mail-yb0-f194.google.com with SMTP id k5-v6so1198517ybo.10; Tue, 28 Aug 2018 14:33:01 -0700 (PDT) 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=6uU+1czB0xcCLwe5eg+rEV09bRkW/K/kWC734SPQmAk=; b=HujmMrFifjs7dGCQ22dCn2PrGxi4elwzSKjCDXCyh3SbWwuGaCv/gKzlAXi8l0lslQ kMMEJRRvY8zxMLm62wvDrwFjxPYSlcJeHQT3d8YaHGDG8vINkuC7LsroCPCKX8lrZkOn bxj3SD3+J/8+HS78xlvbWnjwQgqpmBaUMLJJ8ZNAZFDfN8C9Pzh97+POZ8Aea2nA6Fkz hxubnJXxsoYTpajcQR98Kna73yJowuba9c5x483J0vJCqnEhZ0iW3xyDd1GG6mL1NvIb hXIr2jE8FfhXaZXfb9uRnT+PgujYIsJlMShunsqE4vG/nEOCAp4WwH1t97AMaPA4/iWY exww== 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=6uU+1czB0xcCLwe5eg+rEV09bRkW/K/kWC734SPQmAk=; b=WPLKCbfzI0342+MwBPDcRyNCM5qwofIQRAcgcUL5c8SIdUkeP7I1TgqO6RnLbqXcJ2 yWTcWeqgqS6fh/qG9lL0PUDVaeStJ71s0A/B87qCCz0c6e+IbU67Yd2ml43EyQDH+V59 jJlhJrtElir/Wrn+EgqPw60dpVSF5Nrb9u0FHcA7789yYYe2Kd/F70Vq7XOZIG7Pb6ab lCdb5oCV9mXKYJVN27TNLEutawc0UuMXNwDoJk9Qr4+ZHB70FfAPJ1vMs0NerBbQ8Xh9 YN21JD7Mi+sSDjUN7x3NUCtfPMGQ2qWpK+bZ8gGGo3Wj0dszTdnth9tE1UyC1gItdoLJ BhfQ== X-Gm-Message-State: APzg51BeHFsTteVVWyvJ6LBzslvm18FF3uhQXqCZXnLtU5wVYraygIY7 FHAkmQ7KlJItMntJWcKKbk3yM39peOADIxUsVhg= X-Received: by 2002:a25:1a85:: with SMTP id a127-v6mr1874400yba.507.1535491981072; Tue, 28 Aug 2018 14:33:01 -0700 (PDT) MIME-Version: 1.0 References: <20180828165336.211643-1-salyzyn@android.com> In-Reply-To: <20180828165336.211643-1-salyzyn@android.com> From: Amir Goldstein Date: Wed, 29 Aug 2018 00:32:49 +0300 Message-ID: Subject: Re: [PATCH v5 3/3] overlayfs: override_creds=off option bypass creator_cred To: Mark Salyzyn Cc: linux-kernel , Miklos Szeredi , Jonathan Corbet , Vivek Goyal , "Eric W. Biederman" , Randy Dunlap , Stephen Smalley , overlayfs , linux-doc@vger.kernel.org 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, Aug 28, 2018 at 7:53 PM Mark Salyzyn wrote: > > By default, all access to the upper, lower and work directories is the > recorded mounter's MAC and DAC credentials. The incoming accesses are > checked against the caller's credentials. > > If the principles of least privilege are applied, the mounter's > credentials might not overlap the credentials of the caller's when > accessing the overlayfs filesystem. For example, a file that a lower > DAC privileged caller can execute, is MAC denied to the generally > higher DAC privileged mounter, to prevent an attack vector. > > We add the option to turn off override_creds in the mount options; all > subsequent operations after mount on the filesystem will be only the > caller's credentials. This option default is set in the CONFIG > OVERLAY_FS_OVERRIDE_CREDS or in the module option override_creds. > > The module boolean parameter and mount option override_creds is also > added as a presence check for this "feature" by checking existence of > /sys/module/overlay/parameters/overlay_creds. This will allow user > space to determine if the option can be supplied successfully to the > mount(2) operation. > > Signed-off-by: Mark Salyzyn > Cc: Miklos Szeredi > Cc: Jonathan Corbet > Cc: Vivek Goyal > Cc: Eric W. Biederman > Cc: Amir Goldstein > Cc: Randy Dunlap > Cc: Stephen Smalley > Cc: linux-unionfs@vger.kernel.org > Cc: linux-doc@vger.kernel.org > Cc: linux-kernel@vger.kernel.org > > v2: > - Forward port changed attr to stat, resulting in a build error. > - altered commit message. > > v3: > - Change name from caller_credentials / creator_credentials to the > boolean override_creds. > - Changed from creator to mounter credentials. > - Updated and fortified the documentation. > - Added CONFIG_OVERLAY_FS_OVERRIDE_CREDS > > v4: > - spelling and grammar errors in text > > v5: > - beefed up the caveats in the Documentation > - Is dependent on > "overlayfs: check CAP_DAC_READ_SEARCH before issuing exportfs_decode_fh" > "overlayfs: check CAP_MKNOD before issuing vfs_whiteout" > - Added prwarn when override_creds=off > --- > Documentation/filesystems/overlayfs.txt | 29 +++++++++++++++++++++++++ > fs/overlayfs/Kconfig | 22 +++++++++++++++++++ > fs/overlayfs/copy_up.c | 2 +- > fs/overlayfs/dir.c | 9 ++++---- > fs/overlayfs/inode.c | 16 +++++++------- > fs/overlayfs/namei.c | 6 ++--- > fs/overlayfs/overlayfs.h | 1 + > fs/overlayfs/ovl_entry.h | 1 + > fs/overlayfs/readdir.c | 4 ++-- > fs/overlayfs/super.c | 23 ++++++++++++++++++++ > fs/overlayfs/util.c | 12 ++++++++-- > 11 files changed, 105 insertions(+), 20 deletions(-) > > diff --git a/Documentation/filesystems/overlayfs.txt b/Documentation/filesystems/overlayfs.txt > index 72615a2c0752..953e52971eb0 100644 > --- a/Documentation/filesystems/overlayfs.txt > +++ b/Documentation/filesystems/overlayfs.txt > @@ -106,6 +106,35 @@ Only the lists of names from directories are merged. Other content > such as metadata and extended attributes are reported for the upper > directory only. These attributes of the lower directory are hidden. > > +credentials > +----------- > + > +By default, all access to the upper, lower and work directories is the > +recorded mounter's MAC and DAC credentials. The incoming accesses are > +checked against the caller's credentials. > + > +If the principles of least privilege are applied, the mounter's > +credentials might not overlap the credentials of the caller's when > +accessing the overlayfs filesystem. For example, a file that a lower > +DAC privileged caller can execute, but is MAC denied to the > +generally higher DAC privileged mounter, to prevent an attack vector > +executing with the increased privileges of the mounter. One option is > +to turn off override_creds in the mount options; all subsequent > +operations after mount on the filesystem will be only the caller's > +credentials. This option default is set in the CONFIG > +OVERLAY_FS_OVERRIDE_CREDS or in the module option override_creds. > +Fundamentally The mounter has privileges, its ability to execute, > +for example, files and grant them these higher privileges is to be > +blocked except to lower privileged and appropriate callers. This > +option turned off permits this kind of security policy. > + > +With override_creds turned off, several unintended side effects will > +occur. The caller with a lower privilege will not be able to delete > +files or directories, create nodes, or search some directories. The > +uneven security model where upperdir and workdir are opened at > +privilege, but accessed without, should only be used with strict > +understanding of the side effects and of the security policies. > + > whiteouts and opaque directories > -------------------------------- > > diff --git a/fs/overlayfs/Kconfig b/fs/overlayfs/Kconfig > index 9384164253ac..b55bb0d48415 100644 > --- a/fs/overlayfs/Kconfig > +++ b/fs/overlayfs/Kconfig > @@ -103,3 +103,25 @@ config OVERLAY_FS_XINO_AUTO > For more information, see Documentation/filesystems/overlayfs.txt > > If unsure, say N. > + > +config OVERLAY_FS_OVERRIDE_CREDS > + bool "Overlay filesystem override credentials" > + depends on OVERLAY_FS > + default y > + help > + If set, all access to the upper, lower and work directories is the > + recorded mounter's MAC and DAC credentials. The incoming accesses > + are checked against the caller's credentials. > + > + If the principles of least privilege are applied, the mounter's > + credentials might not overlap the credentials of the caller's when > + accessing the overlayfs filesystem. The mount option > + "override_creds=off" drops the mounter's credential check, so that > + all subsequent operations, after mount, on the filesystem will only > + be the caller's credentials. This option sets the default for the > + module option override_creds, and thus the default for all mounts > + that do not specify this option. > + Was it me that suggested a config option?? because I can't thing of a reason to configure this as the default. ... > > sb->s_root = root_dentry; > + if (!ofs->config.override_creds) > + pr_warn("overlayfs: override_creds=off, uneven security model where mounter privileges do not overlap caller.\n"); > This is not what the user needs to be warned about IMO. User should be warned about consequences. Thanks, Amir.