From: Amir Goldstein <amir73il@gmail.com>
To: Johannes Segitz <jsegitz@suse.com>
Cc: Paul Moore <paul@paul-moore.com>, Vivek Goyal <vgoyal@redhat.com>,
Miklos Szeredi <miklos@szeredi.hu>,
David Anderson <dvander@google.com>,
Mark Salyzyn <salyzyn@android.com>,
Jonathan Corbet <corbet@lwn.net>,
"Eric W . Biederman" <ebiederm@xmission.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 <linux-kernel@vger.kernel.org>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
overlayfs <linux-unionfs@vger.kernel.org>,
LSM List <linux-security-module@vger.kernel.org>,
kernel-team <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, 22 Mar 2023 14:48:29 +0200 [thread overview]
Message-ID: <CAOQ4uxgH905R1dkQy5=tuG4nnB-p2XUWcf91vvYbfu2DyftzPw@mail.gmail.com> (raw)
In-Reply-To: <20230322072850.GA18056@suse.de>
On Wed, Mar 22, 2023 at 9:28 AM Johannes Segitz <jsegitz@suse.com> wrote:
>
> On Fri, Mar 11, 2022 at 03:52:54PM -0500, Paul Moore wrote:
> > On Fri, Mar 11, 2022 at 9:01 AM Vivek Goyal <vgoyal@redhat.com> wrote:
> > > Agreed. After going through the patch set, I was wondering what's the
> > > overall security model and how to visualize that.
> > >
> > > So probably there needs to be a documentation patch which explains
> > > what's the new security model and how does it work.
> >
> > Yes, of course. I'll be sure to add a section to the existing docs.
> >
> > > Also think both in terms of DAC and MAC. (Instead of just focussing too
> > > hard on SELinux).
> >
> > Definitely. Most of what I've been thinking about the past day or so
> > has been how to properly handle some of the DAC/capability issues; I
> > have yet to start playing with the code, but for the most part I think
> > the MAC/SELinux bits are already working properly.
> >
> > > My understanding is that in current model, some of the overlayfs
> > > operations require priviliges. So mounter is supposed to be priviliged
> > > and does the operation on underlying layers.
> > >
> > > Now in this new model, there will be two levels of check. Both overlay
> > > level and underlying layer checks will happen in the context of task
> > > which is doing the operation. So first of all, all tasks will need
> > > to have enough priviliges to be able to perform various operations
> > > on lower layer.
> > >
> > > If we do checks at both the levels in with the creds of calling task,
> > > I guess that probably is fine. (But will require a closer code inspection
> > > to make sure there is no privilege escalation both for mounter as well
> > > calling task).
> >
> > I have thoughts on this, but I don't think I'm yet in a position to
> > debate this in depth just yet; I still need to finish poking around
> > the code and playing with a few things :)
> >
> > It may take some time before I'm back with patches, but I appreciate
> > all of the tips and insight - thank you!
>
> Let me resurrect this discussion. With
> https://github.com/fedora-selinux/selinux-policy/commit/1e8688ea694393c9d918939322b72dfb44a01792
> the Fedora policy changed kernel_t to a confined domain. This means that
> many overlayfs setups that are created in initrd will now run into issues,
> as it will have kernel_t as part of the saved credentials. So while the
> original use case that inspired the patch set was probably not very common
> that now changed.
I don't remember anyone rejecting the patches on the account that
the Android use case is not important. It was never the issue.
>
> It's tricky to work around this. Loading a policy in initrd causes a lot of
> issues now that kernel_t isn't unconfined anymore. Once the policy is
> loaded by systemd changing the mounts is tough since we use it for /etc and
> at this time systemd already has open file handles for policy files in
> /etc.
>
I've already explained several times on this thread what needs to be
done in order to move forward - express the security model and
explain why it is safe.
If the security guys are going to be in LSS in Vancouver, perhaps
we can have a meetup with overlayfs developers on the overlap
day with LSFMM (May 10) to try and figure out a path forward.
Thanks,
Amir.
next prev parent reply other threads:[~2023-03-22 12:48 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
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 [this message]
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='CAOQ4uxgH905R1dkQy5=tuG4nnB-p2XUWcf91vvYbfu2DyftzPw@mail.gmail.com' \
--to=amir73il@gmail.com \
--cc=corbet@lwn.net \
--cc=dvander@google.com \
--cc=ebiederm@xmission.com \
--cc=john.stultz@linaro.org \
--cc=jsegitz@suse.com \
--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=paul@paul-moore.com \
--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).