lkml.org 
[lkml]   [2023]   [Aug]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH v6] vfs, security: Fix automount superblock LSM init problem, preventing NFS sb sharing
Date
Paul Moore <paul@paul-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

\
 
 \ /
  Last update: 2023-08-04 17:18    [W:0.072 / U:0.460 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site