On Thu, Aug 1, 2024 at 8:27 AM Stephen Smalley
<stephen.smalley.work@xxxxxxxxx> wrote:
>
> Given the recent discussion of the SELinux namespaces patches, I
> re-based the working-selinuxns branch of my selinux-kernel fork on top
> of the dev branch. This required first reverting commit e67b79850fcc
> ("selinux: stop passing selinux_state pointers and their offspring")
> which I had created at Linus' request some time ago to avoid the
> extraneous overhead associated with passing those pointers when there
> could only be one selinux_state structure. Due to the number of
> changes, both substantive and coding style related, since the last
> re-base in 2020, there were numerous conflicts that required manual
> resolution. I also checked the coding style of each patch with Paul's
> scripts and fixed any issues introduced by the patches along the way.
>
> The rebase can be found at:
> https://github.com/stephensmalley/selinux-kernel/tree/working-selinuxns
>
> It boots, passes the selinux-testsuite (including the NFS tests), and
> passes the following
> trivial exercising of the unshare mechanism:
> $ sudo bash
> # echo 1 > /sys/fs/selinux/unshare
> # unshare -m -n
> # umount /sys/fs/selinux
> # mount -t selinuxfs none /sys/fs/selinux
> # id
> uid=0(root) gid=0(root) groups=0(root) context=kernel
> # getenforce
> Permissive
> # load_policy
> # id
> uid=0(root) gid=0(root) groups=0(root) context=system_u:system_r:kernel_t:s0
>
> All the same caveats apply - this is still not safe to use and has
> many unresolved issues as noted in the patch descriptions.
Also, note that as before, this branch does NOT include the original
patches to support per-namespace superblock and inode security
structures. Given the known problems with those patches and recent
discussions, we likely don't want them anyway, but for reference they
can still be found here:
https://github.com/stephensmalley/selinux-kernel/commit/3378718ef7d4a837f32c63bdfcc0b70342cdd55d
https://github.com/stephensmalley/selinux-kernel/commit/efb2ddadfdd0e10e75b6aa5da2ed9841df6ef2f6
Without those patches, ls -Z will show as unlabeled any files whose
inodes were already in-core at the time of the creation of the new
SELinux namespace because their inode security structures will have
SIDs that do not exist in the new namespace's SID table.
An alternative approach proposed by Huawei to my original patches can
be found here:
https://lore.kernel.org/selinux/20220216125206.20975-1-igor.baranov@xxxxxxxxxx/#r
However, those patches also seem to have quite a few unresolved issues.
