linux-unionfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Anderson <dvander@google.com>
To: Casey Schaufler <casey@schaufler-ca.com>
Cc: Mark Salyzyn <salyzyn@android.com>,
	Miklos Szeredi <miklos@szeredi.hu>,
	Jonathan Corbet <corbet@lwn.net>, Vivek Goyal <vgoyal@redhat.com>,
	"Eric W . Biederman" <ebiederm@xmission.com>,
	Amir Goldstein <amir73il@gmail.com>,
	Randy Dunlap <rdunlap@infradead.org>,
	Stephen Smalley <sds@tycho.nsa.gov>,
	John Stultz <john.stultz@linaro.org>,
	linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-fsdevel@vger.kernel.org, linux-unionfs@vger.kernel.org,
	linux-security-module@vger.kernel.org, kernel-team@android.com,
	selinux@vger.kernel.org, paulmoore@microsoft.com,
	luca.boccassi@microsoft.com
Subject: Re: [PATCH v19 0/4] overlayfs override_creds=off & nested get xattr fix
Date: Wed, 17 Nov 2021 23:59:12 -0800	[thread overview]
Message-ID: <CA+FmFJCS+CnDmYw3cOCCjNVhMkq6+i6JaSjWAxjgV674_KZtLA@mail.gmail.com> (raw)
In-Reply-To: <a64aa4af-67b1-536c-9bd0-7b34e6cc1abe@schaufler-ca.com>

On Tue, Nov 16, 2021 at 6:18 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
>
> On 11/16/2021 5:58 PM, David Anderson wrote:
> > Mark Salyzyn (3):
> >
> > 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.
>
> This isn't very clear. Are you saying that the security attributes
> of the upper, lower, and work directories are determined by the
> attributes of the process that mounted the filesystem? What is an
> "incoming access"? I'm sure that means something if you're steeped
> in the lore of overlayfs, but it isn't obvious to me.

(Sorry, hitting "Reply All" this time...)

Thanks for taking a look - Yes. An "incoming access" is the user
application security context accessing the filesystem.

> > If the principles of least privilege are applied for sepolicy, the
> > mounter's credentials might not overlap the credentials of the caller's
> > when accessing the overlayfs filesystem.
>
> I'm sorry, but I've tried pretty hard, and can't puzzle that one out.

If your sepolicy is designed to give processes minimal privileges (as ours is),
then "init" might lack privileges even though other processes have them. For
example, init can mount /x but not access /x/y/z. But, process XYZ can access
/x/y/z. In our system processes have no privileges to anything by default,
and permissions are granted as needed, as narrowly as possible.

> DAC privileges are not hierarchical. This doesn't make any sense.

Sorry, that was probably not the right word. The intent was to say that a
process with minimal DAC privileges might be able to access a file, but
a process with expansive DAC privileges might be denied access to the
same file due to MAC restrictions.

> I think I might have figured that one out, but in order to do so
> I have to make way too many assumptions about the earlier paragraph.
> Could you please try to explain what you're doing with more context?

Hopefully the above helps explain: overlayfs uses the mounter's privileges,
which does not work on a system where the mounter does not have a
superset of child processes' privileges. That's the crux of the issue and
I'll keep working on how it's communicated in the patch description.

-David

On Tue, Nov 16, 2021 at 6:18 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
>
> On 11/16/2021 5:58 PM, David Anderson wrote:
> > Mark Salyzyn (3):
> >    Add flags option to get xattr method paired to __vfs_getxattr
> >    overlayfs: handle XATTR_NOSECURITY flag for get xattr method
> >    overlayfs: override_creds=off option bypass creator_cred
> >
> > Mark Salyzyn + John Stultz (1):
> >    overlayfs: inode_owner_or_capable called during execv
> >
> > The first three patches address fundamental security issues that should
> > be solved regardless of the override_creds=off feature.
> >
> > The fourth adds the feature depends on these other fixes.
> >
> > 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.
>
> This isn't very clear. Are you saying that the security attributes
> of the upper, lower, and work directories are determined by the
> attributes of the process that mounted the filesystem? What is an
> "incoming access"? I'm sure that means something if you're steeped
> in the lore of overlayfs, but it isn't obvious to me.
>
> > If the principles of least privilege are applied for sepolicy, the
> > mounter's credentials might not overlap the credentials of the caller's
> > when accessing the overlayfs filesystem.
>
> I'm sorry, but I've tried pretty hard, and can't puzzle that one out.
>
> >    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.
>
> DAC privileges are not hierarchical. This doesn't make any sense.
>
> > 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.
>
> I think I might have figured that one out, but in order to do so
> I have to make way too many assumptions about the earlier paragraph.
> Could you please try to explain what you're doing with more context?
>
> >    The module boolean parameter and mount option
> > override_creds is also added as a presence check for this "feature",
> > existence of /sys/module/overlay/parameters/overlay_creds
> >
> > Signed-off-by: Mark Salyzyn <salyzyn@android.com>
> > Signed-off-by: David Anderson <dvander@google.com>
> > Cc: Miklos Szeredi <miklos@szeredi.hu>
> > Cc: Jonathan Corbet <corbet@lwn.net>
> > Cc: Vivek Goyal <vgoyal@redhat.com>
> > Cc: Eric W. Biederman <ebiederm@xmission.com>
> > Cc: Amir Goldstein <amir73il@gmail.com>
> > Cc: Randy Dunlap <rdunlap@infradead.org>
> > Cc: Stephen Smalley <sds@tycho.nsa.gov>
> > Cc: John Stultz <john.stultz@linaro.org>
> > Cc: linux-doc@vger.kernel.org
> > Cc: linux-kernel@vger.kernel.org
> > Cc: linux-fsdevel@vger.kernel.org
> > Cc: linux-unionfs@vger.kernel.org
> > Cc: linux-security-module@vger.kernel.org
> > Cc: kernel-team@android.com
> > Cc: selinux@vger.kernel.org
> > Cc: paulmoore@microsoft.com
> > Cc: Luca.Boccassi@microsoft.com
> >
> > ---
> >
> > v19
> > - rebase.
> >
> > v18
> > - rebase + fix minor cut and paste error for inode argument in __vfs_getxattr
> >
> > v17
> > - correct some zero-day build failures.
> > - fix up documentation
> >
> > v16
> > - rebase and merge of two patches.
> > - add adjustment to deal with execv when overrides is off.
> >
> > v15
> > - Revert back to v4 with fixes from on the way from v5-v14. The single
> >    structure argument passing to address the complaints about too many
> >    arguments was rejected by the community.
> > - Drop the udner discussion fix for an additional CAP_DAC_READ_SEARCH
> >    check. Can address that independently.
> > - ToDo: upstream test frame for thes security fixes (currently testing
> >    is all in Android).
> >
> > v14:
> > - Rejoin, rebase and a few adjustments.
> >
> > v13:
> > - Pull out first patch and try to get it in alone feedback, some
> >    Acks, and then <crickets> because people forgot why we were doing i.
> >
> > v12:
> > - Restore squished out patch 2 and 3 in the series,
> >    then change algorithm to add flags argument.
> >    Per-thread flag is a large security surface.
> >
> > v11:
> > - Squish out v10 introduced patch 2 and 3 in the series,
> >    then and use per-thread flag instead for nesting.
> > - Switch name to ovl_do_vds_getxattr for __vds_getxattr wrapper.
> > - Add sb argument to ovl_revert_creds to match future work.
> >
> > v10:
> > - Return NULL on CAP_DAC_READ_SEARCH
> > - Add __get xattr method to solve sepolicy logging issue
> > - Drop unnecessary sys_admin sepolicy checking for administrative
> >    driver internal xattr functions.
> >
> > v6:
> > - Drop CONFIG_OVERLAY_FS_OVERRIDE_CREDS.
> > - Do better with the documentation, drop rationalizations.
> > - pr_warn message adjusted to report consequences.
> >
> > 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
> >
> > v4:
> > - spelling and grammar errors in text
> >
> > 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
> >
> > v2:
> > - Forward port changed attr to stat, resulting in a build error.
> > - altered commit message.
> >
> > David Anderson (4):
> >    Add flags option to get xattr method paired to __vfs_getxattr
> >    overlayfs: handle XATTR_NOSECURITY flag for get xattr method
> >    overlayfs: override_creds=off option bypass creator_cred
> >    overlayfs: inode_owner_or_capable called during execv
> >
> >   Documentation/filesystems/locking.rst   |  2 +-
> >   Documentation/filesystems/overlayfs.rst | 26 ++++++++++++++-
> >   fs/9p/acl.c                             |  3 +-
> >   fs/9p/xattr.c                           |  3 +-
> >   fs/afs/xattr.c                          | 10 +++---
> >   fs/attr.c                               |  2 +-
> >   fs/btrfs/xattr.c                        |  3 +-
> >   fs/ceph/xattr.c                         |  3 +-
> >   fs/cifs/xattr.c                         |  2 +-
> >   fs/ecryptfs/inode.c                     |  6 ++--
> >   fs/ecryptfs/mmap.c                      |  5 +--
> >   fs/erofs/xattr.c                        |  3 +-
> >   fs/ext2/xattr_security.c                |  2 +-
> >   fs/ext2/xattr_trusted.c                 |  2 +-
> >   fs/ext2/xattr_user.c                    |  2 +-
> >   fs/ext4/xattr_hurd.c                    |  2 +-
> >   fs/ext4/xattr_security.c                |  2 +-
> >   fs/ext4/xattr_trusted.c                 |  2 +-
> >   fs/ext4/xattr_user.c                    |  2 +-
> >   fs/f2fs/xattr.c                         |  4 +--
> >   fs/fuse/xattr.c                         |  4 +--
> >   fs/gfs2/xattr.c                         |  3 +-
> >   fs/hfs/attr.c                           |  2 +-
> >   fs/hfsplus/xattr.c                      |  3 +-
> >   fs/hfsplus/xattr_security.c             |  3 +-
> >   fs/hfsplus/xattr_trusted.c              |  3 +-
> >   fs/hfsplus/xattr_user.c                 |  3 +-
> >   fs/inode.c                              |  7 +++--
> >   fs/internal.h                           |  3 +-
> >   fs/jffs2/security.c                     |  3 +-
> >   fs/jffs2/xattr_trusted.c                |  3 +-
> >   fs/jffs2/xattr_user.c                   |  3 +-
> >   fs/jfs/xattr.c                          |  5 +--
> >   fs/kernfs/inode.c                       |  3 +-
> >   fs/nfs/nfs4proc.c                       |  9 ++++--
> >   fs/ntfs3/xattr.c                        |  2 +-
> >   fs/ocfs2/xattr.c                        |  9 ++++--
> >   fs/open.c                               |  2 +-
> >   fs/orangefs/xattr.c                     |  3 +-
> >   fs/overlayfs/copy_up.c                  |  2 +-
> >   fs/overlayfs/dir.c                      | 17 +++++-----
> >   fs/overlayfs/file.c                     | 25 ++++++++-------
> >   fs/overlayfs/inode.c                    | 29 ++++++++---------
> >   fs/overlayfs/namei.c                    |  6 ++--
> >   fs/overlayfs/overlayfs.h                |  7 +++--
> >   fs/overlayfs/ovl_entry.h                |  1 +
> >   fs/overlayfs/readdir.c                  |  8 ++---
> >   fs/overlayfs/super.c                    | 34 ++++++++++++++++----
> >   fs/overlayfs/util.c                     | 13 ++++++--
> >   fs/posix_acl.c                          |  2 +-
> >   fs/reiserfs/xattr_security.c            |  3 +-
> >   fs/reiserfs/xattr_trusted.c             |  3 +-
> >   fs/reiserfs/xattr_user.c                |  3 +-
> >   fs/squashfs/xattr.c                     |  2 +-
> >   fs/ubifs/xattr.c                        |  3 +-
> >   fs/xattr.c                              | 42 +++++++++++++------------
> >   fs/xfs/xfs_xattr.c                      |  3 +-
> >   include/linux/lsm_hook_defs.h           |  3 +-
> >   include/linux/security.h                |  6 ++--
> >   include/linux/xattr.h                   |  6 ++--
> >   include/uapi/linux/xattr.h              |  7 +++--
> >   mm/shmem.c                              |  3 +-
> >   net/socket.c                            |  3 +-
> >   security/commoncap.c                    | 11 ++++---
> >   security/integrity/evm/evm_main.c       | 13 +++++---
> >   security/security.c                     |  5 +--
> >   security/selinux/hooks.c                | 19 ++++++-----
> >   security/smack/smack_lsm.c              | 18 ++++++-----
> >   68 files changed, 289 insertions(+), 167 deletions(-)
> >

  reply	other threads:[~2021-11-18  7:59 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-17  1:58 [PATCH v19 0/4] overlayfs override_creds=off & nested get xattr fix David Anderson
2021-11-17  1:58 ` [PATCH v19 1/4] Add flags option to get xattr method paired to __vfs_getxattr David Anderson
2021-11-17 16:13   ` kernel test robot
2022-03-25 11:02   ` Luca Weiss
2022-03-25 14:44     ` Paul Moore
2021-11-17  1:58 ` [PATCH v19 2/4] overlayfs: handle XATTR_NOSECURITY flag for get xattr method David Anderson
2021-11-17  1:58 ` [PATCH v19 3/4] overlayfs: override_creds=off option bypass creator_cred David Anderson
2021-11-17  1:58 ` [PATCH v19 4/4] overlayfs: inode_owner_or_capable called during execv David Anderson
2021-11-17  2:18 ` [PATCH v19 0/4] overlayfs override_creds=off & nested get xattr fix Casey Schaufler
2021-11-18  7:59   ` David Anderson [this message]
2021-11-17  7:36 ` Amir Goldstein
2021-11-18  9:53   ` David Anderson
2021-11-18 10:20     ` Amir Goldstein
2021-11-18 20:15       ` David Anderson
2021-11-18 20:32         ` Amir Goldstein
2021-12-03 15:37   ` Vivek Goyal
2021-12-03 16:04     ` Paul Moore
2021-12-03 16:31     ` Amir Goldstein
2021-12-03 18:34       ` Vivek Goyal
2022-03-01  1:09         ` Paul Moore
     [not found]           ` <CA+FmFJA-r+JgMqObNCvE_X+L6jxWtDrczM9Jh0L38Fq-6mnbbA@mail.gmail.com>
2022-03-09 21:13             ` Paul Moore
2022-03-10 22:11               ` Paul Moore
2022-03-11  4:09                 ` Amir Goldstein
2022-03-11 14:01                   ` Vivek Goyal
2022-03-11 20:52                     ` Paul Moore
2023-03-22  7:28                       ` Johannes Segitz
2023-03-22 12:48                         ` Amir Goldstein
2023-03-22 14:07                           ` Paul Moore
2023-03-22 14:05                         ` Paul Moore

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CA+FmFJCS+CnDmYw3cOCCjNVhMkq6+i6JaSjWAxjgV674_KZtLA@mail.gmail.com \
    --to=dvander@google.com \
    --cc=amir73il@gmail.com \
    --cc=casey@schaufler-ca.com \
    --cc=corbet@lwn.net \
    --cc=ebiederm@xmission.com \
    --cc=john.stultz@linaro.org \
    --cc=kernel-team@android.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=linux-unionfs@vger.kernel.org \
    --cc=luca.boccassi@microsoft.com \
    --cc=miklos@szeredi.hu \
    --cc=paulmoore@microsoft.com \
    --cc=rdunlap@infradead.org \
    --cc=salyzyn@android.com \
    --cc=sds@tycho.nsa.gov \
    --cc=selinux@vger.kernel.org \
    --cc=vgoyal@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).