linux-kernel - Re: [PATCH v6] vfs, security: Fix automount superblock LSM init problem, preventing NFS sb sharing

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <2678222.1691162178@warthog.procyon.org.uk>
Date:   Fri, 04 Aug 2023 16:16:18 +0100
From:   David Howells <dhowells@...hat.com>
To:     Paul Moore <paul@...l-moore.com>
Cc:     dhowells@...hat.com, Jeff Layton <jlayton@...nel.org>,
        Alexander Viro <viro@...iv.linux.org.uk>,
        Christian Brauner <brauner@...nel.org>,
        Trond Myklebust <trond.myklebust@...merspace.com>,
        Anna Schumaker <anna@...nel.org>,
        James Morris <jmorris@...ei.org>,
        "Serge E. Hallyn" <serge@...lyn.com>,
        Stephen Smalley <stephen.smalley.work@...il.com>,
        Eric Paris <eparis@...isplace.org>,
        Casey Schaufler <casey@...aufler-ca.com>,
        Scott Mayhew <smayhew@...hat.com>,
        Stephen Smalley <sds@...ho.nsa.gov>,
        linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-nfs@...r.kernel.org, linux-security-module@...r.kernel.org,
        selinux@...r.kernel.org
Subject: Re: [PATCH v6] vfs, security: Fix automount superblock LSM init problem, preventing NFS sb sharing

Paul Moore <paul@...l-moore.com> wrote:

> 
> I generally dislike core kernel code which makes LSM calls conditional
> on some kernel state maintained outside the LSM.  Sometimes it has to
> be done as there is no other good options, but I would like us to try
> and avoid it if possible.  The commit description mentioned that this
> was put here to avoid a SELinux complaint, can you provide an example
> of the complain?  Does it complain about a double/invalid mount, e.g.
> "SELinux: mount invalid.  Same superblock, different security ..."?
> 
> I'd like to understand why the sb_set_mnt_opts() call fails when it
> comes after the fs_context_init() call.  I'm particulary curious to
> know if the failure is due to conflicting SELinux state in the
> fs_context, or if it is simply an issue of sb_set_mnt_opts() not
> properly handling existing values.  Perhaps I'm being overly naive,
> but I'm hopeful that we can address both of these within the SELinux
> code itself.
> 
> In a worst case situation, we could always implement a flag *inside*
> the SELinux code, similar to what has been done with 'lsm_set' here.

IIRC, the issue is when you make a mount with an explicit context= setting and
make another mount from some way down the export tree that doesn't have an
explicit setting, e.g.:

	mount carina:/ /mnt -o context=system_u:object_r:root_t:s0
	mount carina:/nfs/scratch /mnt2

and then cause an automount to walk from one to the other:

	stat /mnt/nfs/scratch/foo

For reference, my server has:

	/nfs/scratch 192.168.6.0/255.255.255.0,90.155.74.16/255.255.255.248
	/nfs         192.168.6.0/255.255.255.0,90.155.74.16/255.255.255.248
	/            192.168.6.0/255.255.255.0,90.155.74.16/255.255.255.248

and if I look in /proc/fs/nfsfs/volumes, I can see the individual superblocks:

	NV SERVER   PORT DEV          FSID                              FSC
	v4 c0a80601  801 0:51         0:0                               no 
	v4 c0a80601  801 0:56         3:0                               no 
	v4 c0a80601  801 0:52         1:0                               no 
	v4 c0a80601  801 0:55         3:0                               no 

As you can see, there are two referring to the same 'volume'.

Without the "fc->lsm_set=true" bit, you get an error something like:

	SELinux: mount invalid.  Same superblock, different security settings for (dev 0:56, type nfs4)

One important question is how should sharing of a mount with unspecified
context be handled when we try to unify it with a mount that has an explicit
context?

David