On Fri, 2021-12-03 at 13:06 -0500, Stefan Berger wrote:
On 12/3/21 12:03, James Bottomley wrote:Well securityfs is supposed to exist for LSMs. At some point each of
On Thu, 2021-12-02 at 21:31 -0500, Stefan Berger wrote:I had thought about this also but the rationale was:
[...]
static int securityfs_init_fs_context(struct fs_context *fc)I know I suggested this, but to get this to work in general, it's
{
+ 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;
}
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:
securityfs is compiled due to CONFIG_IMA_NS and the user namespace
exists there and that has a pointer now to ima_namespace, which can
have that callback. I assumed that other namespaced subsystems could
also be reached then via such a callback, but I don't know.
those is going to need to be namespaced, which may eventually be quite
a pile of callbacks, which is why I thought of a notifier.
I suppose any late filesystem init callchain would have to beI don't think so; I think just moving some securityfs entries into the
connected to the user_namespace somehow?
user_namespace and managing the notifier chain from within securityfs
will do for now. [although I'd have to spec this out in code before I
knew for sure].
Right, it's being activated by securityfs_ns_create_mount which isWhat I don't like about the fill_super is that it gets called too+int ima_fs_ns_init(struct ima_namespace *ns)This actually triggers on the call to securityfs_init_fs_context,
+{
+ ns->mount = securityfs_ns_create_mount(ns->user_ns);
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 anyconsumer of securityfs can be namespaced by
registering for this notifier.
early:
[ 67.058611] securityfs_ns_create_mount @ 102 target user_ns:
ffff95c010698c80; nr_extents: 0
[ 67.059836] securityfs_fill_super @ 47 user_ns:
ffff95c010698c80;
nr_extents: 0
called as soon as the user_ns is created.
We are switching to the target user namespace inExactly, so I was thinking of not having a securityfs_ns_create_mount
securityfs_ns_create_mount. The expected nr_extents at this point is
0, since user_ns hasn't been configured, yet. But then
security_fill_super is also called with nr_extents 0. We cannot use
that, it's too early!
at all. All the securityfs_ns_create.. calls would be in the notifier
Where would the vfsmount pointer reside? For now it's inexactly. I think struct user_namespace should have two elements gated
ima_namespace, but it sounds like it should be in a more centralized
place? Should it also be connected to the user_namespace so we can
pick it up using get_user_ns()?
by a #ifdef CONFIG_SECURITYFS which are the vfsmount and the
mount_count for passing into simple_pin_fs.
James