From: Christian Brauner <brauner@kernel.org>
To: Amir Goldstein <amir73il@gmail.com>
Cc: Miklos Szeredi <miklos@szeredi.hu>,
"Darrick J . Wong" <djwong@kernel.org>,
Al Viro <viro@zeniv.linux.org.uk>, Christoph Hellwig <hch@lst.de>,
Seth Forshee <sforshee@kernel.org>,
Yang Xu <xuyang2018.jy@fujitsu.com>,
Filipe Manana <fdmanana@kernel.org>,
linux-unionfs@vger.kernel.org, linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH v2 3/5] attr: use consistent sgid stripping checks
Date: Tue, 11 Oct 2022 15:48:38 +0200 [thread overview]
Message-ID: <20221011134838.3tkh3xroqnnkeydo@wittgenstein> (raw)
In-Reply-To: <CAOQ4uxhGqCkzsugEd_TZ+s3FEKiAxQtBy1rm3KP4KS=hzTsf4w@mail.gmail.com>
On Tue, Oct 11, 2022 at 02:07:10PM +0300, Amir Goldstein wrote:
> > > > @@ -721,10 +721,10 @@ int chown_common(const struct path *path, uid_t user, gid_t group)
> > > > return -EINVAL;
> > > > if ((group != (gid_t)-1) && !setattr_vfsgid(&newattrs, gid))
> > > > return -EINVAL;
> > > > - if (!S_ISDIR(inode->i_mode))
> > > > - newattrs.ia_valid |=
> > > > - ATTR_KILL_SUID | ATTR_KILL_SGID | ATTR_KILL_PRIV;
> > > > inode_lock(inode);
> > > > + if (!S_ISDIR(inode->i_mode))
> > > > + newattrs.ia_valid |= ATTR_KILL_SUID | ATTR_KILL_PRIV |
> > > > + should_remove_sgid(mnt_userns, inode);
> > >
> > > This is making me stop and wonder:
> > > 1. This has !S_ISDIR, should_remove_suid() has S_ISREG and
> > > setattr_drop_sgid() has neither - is this consistent?
> >
> > I thought about that. It'very likely redundant since we deal with that
> > in other parts but I need to verify all callers before we can remove
> > that.
> >
> > > 2. SUID and PRIV are removed unconditionally and SGID is
> > > removed conditionally - this is not a change of behavior
> > > (at least for non-overlayfs), but is it desired???
> >
> > It looks that way but it isn't. The setgid bit was only killed
> > unconditionally for S_IXGRP. We continue to do that. But it was always
> > removed conditionally for ~S_IXGRP. The difference between this patchset
> > and earlier is that it was done in settattr_prepare() or setattr_copy()
> > before this change.
> >
> > IOW, we raised ATTR_KILL_SGID unconditionally but then only
> > conditionally obeyed it in setattr_{prepare,copy}() whereas now we
> > conditionally raise ATTR_KILL_SGID. That's surely a slight change but it
> > just means that we don't cause bugs for filesystems that roll their own
> > prepare or copy helpers and is just nicer overall.
> >
>
> Yes, that sounds right.
>
> The point that I was trying to make and failed to articulate myself was
> that chown_common() raises ATTR_KILL_SUID unconditionally,
> while should_remove_suid() raises ATTR_KILL_SUID conditional
> to !capable(CAP_FSETID).
>
> Is this inconsistency in stripping SUID desired?
I looked at this before and it likely isn't intentional. But I need to
do pre-git archeology to determine that after I'm back from PTO. It
likely is something we can tackle.
>
> According to man page (I think that) it is:
>
> "When the owner or group of an executable file is changed by an
> unprivileged user, the S_ISUID and S_ISGID mode bits are cleared.
> POSIX does not specify whether this also should happen when root
> does the chown(); the Linux behavior depends on the kernel version,
> and since Linux 2.2.13, root is treated like other users..."
>
> So special casing SUID stripping in chown() looks intentional,
> but maybe it is worth a comment.
It definitely is worth a comment but I think instead we should in the
future risk changing this for the write path as well. Because right now
losing the S_ISGID bit during chown() for regular files unconditionally
is important to not accidently have root create a situation where they
open a way for an unprivileged user to escalate privileges when chowning
a non-root owned setuid binary to a root-owned setuid binary:
touch aaa
chown 1000:1000
chmod u+s aaa
sudo chown aaa
and if the setuid bit would be retained then an unpriv user can now
abuse the setuid binary - if they can execute ofc. So that's why it's
dropped unconditionally. However, if that is a valid attack scenario
then a write should also drop setuid unconditionally since a non-harmful
setuid binary could be changed to a harmful one.
>
> The paragraph above *may* be interpreted that chown() should strip
> S_SGID|S_IXGRP regardless of CAP_FSETID, which, as you say,
> has not been the case for a while.
Yeah, for the setgid bit we've been dropping it implicitly currently.
Thanks!
Christian
next prev parent reply other threads:[~2022-10-11 13:48 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-07 14:05 [PATCH v2 0/5] fs: improve setgid stripping consistency even more Christian Brauner
2022-10-07 14:05 ` [PATCH v2 1/5] attr: add setattr_drop_sgid() Christian Brauner
2022-10-11 8:11 ` Amir Goldstein
2022-10-11 8:57 ` Christian Brauner
2022-10-07 14:05 ` [PATCH v2 2/5] attr: add should_remove_sgid() Christian Brauner
[not found] ` <202210080357.inSALqdT-lkp@intel.com>
2022-10-08 5:56 ` Christian Brauner
2022-10-11 8:18 ` Amir Goldstein
2022-10-11 8:46 ` Christian Brauner
2022-10-07 14:05 ` [PATCH v2 3/5] attr: use consistent sgid stripping checks Christian Brauner
2022-10-11 8:43 ` Amir Goldstein
2022-10-11 8:56 ` Christian Brauner
2022-10-11 11:07 ` Amir Goldstein
2022-10-11 13:48 ` Christian Brauner [this message]
2022-10-07 14:05 ` [PATCH v2 4/5] ovl: remove privs in ovl_copyfile() Christian Brauner
2022-10-07 14:05 ` [PATCH v2 5/5] ovl: remove privs in ovl_fallocate() Christian Brauner
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=20221011134838.3tkh3xroqnnkeydo@wittgenstein \
--to=brauner@kernel.org \
--cc=amir73il@gmail.com \
--cc=djwong@kernel.org \
--cc=fdmanana@kernel.org \
--cc=hch@lst.de \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-unionfs@vger.kernel.org \
--cc=miklos@szeredi.hu \
--cc=sforshee@kernel.org \
--cc=viro@zeniv.linux.org.uk \
--cc=xuyang2018.jy@fujitsu.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).