linux-unionfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Johannes Segitz <jsegitz@suse.com>
To: Paul Moore <paul@paul-moore.com>
Cc: Amir Goldstein <amir73il@gmail.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 08:28:50 +0100	[thread overview]
Message-ID: <20230322072850.GA18056@suse.de> (raw)
In-Reply-To: <CAHC9VhQ+x3ko+=oU-P+w4ssqyyskRxaKsBGJLnXtP_NzWNuxHg@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 3058 bytes --]

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.

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.

Johannes
-- 
GPG Key                EE16 6BCE AD56 E034 BFB3  3ADD 7BF7 29D5 E7C8 1FA0
Subkey fingerprint:    250F 43F5 F7CE 6F1E 9C59  4F95 BC27 DD9D 2CC4 FD66
SUSE Software Solutions Germany GmbH, Frankenstraße 146, 90461 Nürnberg, Germany
Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
(HRB 36809, AG Nürnberg)

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2023-03-22  7:29 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 [this message]
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=20230322072850.GA18056@suse.de \
    --to=jsegitz@suse.com \
    --cc=amir73il@gmail.com \
    --cc=corbet@lwn.net \
    --cc=dvander@google.com \
    --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=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).