libselinux: add selinux_unshare() and is_selinux_unshared()

[stephensmalley]

Provide a selinux_unshare() wrapper for
lsm_set_self_attr(LSM_ATTR_UNSHARE, ...) and other required processing when unsharing the SELinux namespace, and an is_selinux_unshared() wrapper for lsm_get_self_attr(LSM_ATTR_UNSHARE, ...) for detecting whether one is in an unshared SELinux namespace that has not yet been fully initialized.

Add a selinux_unshare() interface to unshare the SELinux namespace, and an unshareselinux utility to run a shell or command in its own SELinux and mount namespaces. The selinux_unshare() interface expects the caller to have already unshared its mount namespace and created a MS_REC|MS_PRIVATE mount of / prior to invoking it so that it can freely modify the selinuxfs mount as needed by the unshare operation. The unshareselinux utility demonstrates how to do this prior to calling selinux_unshare(). Upon a successful return from selinux_unshare(), the SELinux namespace will be unshared and there will be no selinuxfs mount on /sys/fs/selinux. The caller can then proceed to mount a new selinuxfs filesystem private to the new namespace, load a policy, set enforcing mode, etc, as is commonly handled by init/systemd during boot.

Add an is_selinux_unshared() interface to detect whether one is in an unshared SELinux namespace that has not yet been fully initialized (i.e. no policy loaded yet), and a selinuxunshared utility to use it from a shell or script. The is_selinux_unshared() interface returns 1 iff the SELinux namespace has been unshared and has not yet been fully initialized. It returns 0 if SELinux namespaces are not supported or the namespace has not been unshared or the namespace has been fully initialized. If lsm_get_self_attr(2) return -1 with an errno other than ENOSYS (not implemented) or EOPNOTSUPP (not supported by any active LSM), then is_selinux_unshared() will return -1 with the same errno.

Please read CONTRIBUTING.md

Contributing Code

Post the patch for the review to the
SELinux mailing list at
[email protected].

When preparing patches, please follow these guidelines:

• Patches should apply with git am
• Must apply against HEAD of the main branch
• Separate large patches into logical patches
• Patch descriptions must end with your "Signed-off-by" line. This means your
  code meets the Developer's certificate of origin, see below.

[stephensmalley]

This is just to trigger CI testing, not for actual merging.