From: James Bottomley <jejb@linux.ibm.com>
To: Stefan Berger <stefanb@linux.ibm.com>, linux-integrity@vger.kernel.org
Cc: zohar@linux.ibm.com, serge@hallyn.com,
christian.brauner@ubuntu.com, containers@lists.linux.dev,
dmitry.kasatkin@gmail.com, ebiederm@xmission.com,
krzysztof.struczynski@huawei.com, roberto.sassu@huawei.com,
mpeters@redhat.com, lhinds@redhat.com, lsturman@redhat.com,
puiterwi@redhat.com, jamjoom@us.ibm.com,
linux-kernel@vger.kernel.org, paul@paul-moore.com,
rgb@redhat.com, linux-security-module@vger.kernel.org,
jmorris@namei.org
Subject: Re: [RFC v2 19/19] ima: Setup securityfs for IMA namespace
Date: Fri, 03 Dec 2021 12:03:41 -0500 [thread overview]
Message-ID: <df433bc52ca1e0408d48bbace4c34a573991f5ba.camel@linux.ibm.com> (raw)
In-Reply-To: <20211203023118.1447229-20-stefanb@linux.ibm.com>
On Thu, 2021-12-02 at 21:31 -0500, Stefan Berger wrote:
[...]
> static int securityfs_init_fs_context(struct fs_context *fc)
> {
> + int rc;
> +
> + if (fc->user_ns->ima_ns->late_fs_init) {
> + rc = fc->user_ns->ima_ns->late_fs_init(fc->user_ns);
> + if (rc)
> + return rc;
> + }
> fc->ops = &securityfs_context_ops;
> return 0;
> }
I know I suggested this, but to get this to work in general, it's going
to have to not be specific to IMA, so it's going to have to become
something generic like a notifier chain. The other problem is it's
only working still by accident:
> +int ima_fs_ns_init(struct ima_namespace *ns)
> +{
> + ns->mount = securityfs_ns_create_mount(ns->user_ns);
This actually triggers on the call to securityfs_init_fs_context, but
nothing happens because the callback is null. Every subsequent use of
fscontext will trigger this. The point of a keyed supeblock is that
fill_super is only called once per key, that's the place we should be
doing this. It should also probably be a blocking notifier so any
consumer of securityfs can be namespaced by registering for this
notifier.
> + if (IS_ERR(ns->mount)) {
> + ns->mount = NULL;
> + return -1;
> + }
> + ns->mount_count = 1;
This is a bit nasty, too: we're spilling the guts of mount count
tracking into IMA instead of encapsulating it inside securityfs.
> +
> + /* Adjust the trigger for user namespace's early teardown of
> dependent
> + * namespaces. Due to the filesystem there's an additional
> reference
> + * to the user namespace.
> + */
> + ns->user_ns->refcount_teardown += 1;
> +
> + ns->late_fs_init = ima_fs_ns_late_init;
> +
> + return 0;
> +}
I think what should be happening is that we shouldn't so the
simple_pin_fs, which creates the inodes, ahead of time; we should do it
inside fill_super using a notifier, meaning it gets called once per
key, creates the root dentry then triggers the notifier which
instantiates all the namespaced entries. We can still use
simple_pin_fs for this because there's no locking across fill_super.
This would mean fill_super would be called the first time the
securityfs is mounted inside the namespace.
If we do it this way, we can now make securityfs have its own mount and
mount_count inside the user namespace, which it uses internally to the
securityfs code, thus avoiding exposing them to ima or any other
namespaced consumer.
I also think we now don't need the securityfs_ns_ duplicated functions
because the callback via the notifier chain now ensures we can use the
namespace they were created in to distinguish between non namespaced
and namespaced entries.
So non-namespaced consumers of securityfs would do what they do now
(calling the securityfs_create on initialization) and namespaced
consumers would register a callback on the notifier which would get
called once for every namespace the securityfs gets mounted in.
I also theorize if we do it with notifiers, we could have a notifier on
kill_sb to tear down all the entires. If we do this, I think we don't
have to pin any more.
James
next prev parent reply other threads:[~2021-12-03 17:04 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-03 2:30 [RFC v2 00/19] ima: Namespace IMA with audit support in IMA-ns Stefan Berger
2021-12-03 2:31 ` [RFC v2 01/19] ima: Add IMA namespace support Stefan Berger
2021-12-03 2:31 ` [RFC v2 02/19] ima: Define ns_status for storing namespaced iint data Stefan Berger
2021-12-03 2:31 ` [RFC v2 03/19] ima: Namespace audit status flags Stefan Berger
2021-12-03 2:31 ` [RFC v2 04/19] ima: Move delayed work queue and variables into ima_namespace Stefan Berger
2021-12-03 2:31 ` [RFC v2 05/19] ima: Move IMA's keys queue related " Stefan Berger
2021-12-03 2:31 ` [RFC v2 06/19] ima: Move policy " Stefan Berger
2021-12-03 2:31 ` [RFC v2 07/19] ima: Move ima_htable " Stefan Berger
2021-12-03 2:31 ` [RFC v2 08/19] ima: Move measurement list related variables " Stefan Berger
2021-12-03 2:31 ` [RFC v2 09/19] ima: Only accept AUDIT rules for IMA non-init_ima_ns namespaces for now Stefan Berger
2021-12-03 2:31 ` [RFC v2 10/19] ima: Implement hierarchical processing of file accesses Stefan Berger
2021-12-03 2:31 ` [RFC v2 11/19] securityfs: Prefix global variables with securityfs_ Stefan Berger
2021-12-03 2:31 ` [RFC v2 12/19] securityfs: Pass static variables as parameters from top level functions Stefan Berger
2021-12-03 2:31 ` [RFC v2 13/19] securityfs: Extend securityfs with namespacing support Stefan Berger
2021-12-03 2:31 ` [RFC v2 14/19] ima: Move some IMA policy and filesystem related variables into ima_namespace Stefan Berger
2021-12-03 2:31 ` [RFC v2 15/19] capabilities: Introduce CAP_INTEGRITY_ADMIN Stefan Berger
2021-12-03 16:40 ` Casey Schaufler
2021-12-03 17:39 ` Stefan Berger
2021-12-03 2:31 ` [RFC v2 16/19] ima: Use integrity_admin_ns_capable() to check corresponding capability Stefan Berger
2021-12-03 2:31 ` [RFC v2 17/19] userns: Introduce a refcount variable for calling early teardown function Stefan Berger
2021-12-03 2:31 ` [RFC v2 18/19] ima/userns: Define early teardown function for IMA namespace Stefan Berger
2021-12-03 2:31 ` [RFC v2 19/19] ima: Setup securityfs " Stefan Berger
2021-12-03 15:07 ` Stefan Berger
2021-12-03 17:03 ` James Bottomley [this message]
2021-12-03 18:06 ` Stefan Berger
2021-12-03 18:50 ` James Bottomley
2021-12-03 19:11 ` Stefan Berger
2021-12-04 0:33 ` Stefan Berger
2021-12-06 11:52 ` Christian Brauner
2021-12-06 4:27 ` James Bottomley
2021-12-06 14:03 ` Stefan Berger
2021-12-06 14:11 ` James Bottomley
2021-12-06 17:22 ` Stefan Berger
2021-12-03 19:37 ` Casey Schaufler
2021-12-06 12:08 ` Christian Brauner
2021-12-06 13:38 ` James Bottomley
2021-12-06 14:13 ` Christian Brauner
2021-12-06 15:44 ` Christian Brauner
2021-12-06 16:25 ` James Bottomley
2021-12-06 14:11 ` Christian Brauner
2021-12-06 14:21 ` James Bottomley
2021-12-06 14:42 ` Christian Brauner
2021-12-06 14:51 ` James Bottomley
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=df433bc52ca1e0408d48bbace4c34a573991f5ba.camel@linux.ibm.com \
--to=jejb@linux.ibm.com \
--cc=christian.brauner@ubuntu.com \
--cc=containers@lists.linux.dev \
--cc=dmitry.kasatkin@gmail.com \
--cc=ebiederm@xmission.com \
--cc=jamjoom@us.ibm.com \
--cc=jmorris@namei.org \
--cc=krzysztof.struczynski@huawei.com \
--cc=lhinds@redhat.com \
--cc=linux-integrity@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=lsturman@redhat.com \
--cc=mpeters@redhat.com \
--cc=paul@paul-moore.com \
--cc=puiterwi@redhat.com \
--cc=rgb@redhat.com \
--cc=roberto.sassu@huawei.com \
--cc=serge@hallyn.com \
--cc=stefanb@linux.ibm.com \
--cc=zohar@linux.ibm.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).