Setting context in early boot

[Frederick Grose]

I have a general scoping question on setting SELinux context on files/directories during early boot.
I'm working on a feature in dracut to implement general stacking of filesystem hierarchies via OverlayFS for the root filesystem within the dmsquash-live-root module.
How should I address the setting of context for new files, directories, or links needed to assemble the components for the OverlayFS mount?

For example, when I 
  mkdir -m 0755 -p --context=system_u:object_r:root_t:s0 /run/somemountpoint
I get this warning in the journal:
  mkdir: warning: ignoring --context; it requires an SELinux/SMACK-enabled kernel

If the SELinux code is not active at this early stage, what is to be done?

[justina colmena ~biz]

On September 5, 2022 10:52:39 AM AKDT, Frederick Grose  wrote:
> If the SELinux code is not active at this early stage, what is to be done?

Some parts of it are still functional, curiously enough, but SELinux is mostly an abandoned NSA government surveillance intelligence project once intended or perhaps proposed for dealing with sensitive departmental information at Official Use Only, Confidential, Secret, and Top Secret levels etc. -- but since online hacking, industrial espionage, and thievery in law are always much more profitable than actual "security" (national or otherwise)  -- the only *real* answer you will likely get on this list is akin to the sound of your own voice echoing through the concrete hallways of a long-abandoned federal government military industrial complex building.

[Ondrej Mosnacek]

On Mon, Sep 5, 2022 at 8:52 PM Frederick Grose  wrote:
> I have a general scoping question on setting SELinux context on files/directories during early boot.
> I'm working on a feature in dracut to implement general stacking of filesystem hierarchies via OverlayFS for the root filesystem within the dmsquash-live-root module.
> How should I address the setting of context for new files, directories, or links needed to assemble the components for the OverlayFS mount?
>
> For example, when I
>   mkdir -m 0755 -p --context=system_u:object_r:root_t:s0 /run/somemountpoint
> I get this warning in the journal:
>   mkdir: warning: ignoring --context; it requires an SELinux/SMACK-enabled kernel
>
> If the SELinux code is not active at this early stage, what is to be done?

Tools that use libselinux to set labels will probably refuse to work
with SELinux policy not yet loaded, but if you have a recent enough
kernel (5.5+), it should be possible to set the extended attribute
manually - for example using setfattr:

mkdir -m 0755 -p /run/somemountpoint
setfattr -n security.selinux -v system_u:object_r:root_t:s0 /run/somemountpoint

[Frederick Grose]

Picking up this topic again:
In Fedora,
when an .iso file is booted with an OverlayFS overlay in the /run tmpfs at /run/overlayfs, the root filesystem is mounted as
`mount LiveOS_rootfs /sysroot -t overlay -o lowerdir=/run/rootfsbase,upperdir=/run/overlayfs,workdir=/run/ovlwork`

If SELinux is active, one may
mkdir --context=system_u:object_r:root_t:s0 /sysroot /run/overlayfs /run/ovlwork
mount LiveOS_rootfs /sysroot -t overlay -o rootcontext=@target,lowerdir=/run/rootfsbase,upperdir=/run/overlayfs,workdir=/run/ovlwork`
(See https://github.com/util-linux/util-linux/issues/1830.)

But SELinux is not active in the initramfs,
and after switch-root, the root directory inherits context type tmpfs_t and /run/overlayfs and /run/ovlwork are labeled with var_run_t.

Here are some reported problems:
https://github.com/dracut-ng/dracut-ng/issues/1042
        Microsoft decided to activate SELinux in the initramfs (https://github.com/microsoft/azurelinux/pull/11198),
        but Fedora has no such plans, https://github.com/fedora-selinux/selinux-policy/issues/2221.
https://bugzilla.redhat.com/show_bug.cgi?id=2404788
https://github.com/dracut-ng/dracut-ng/issues/377

`setfattr -n security.selinux -v system_u:object_r:root_t:s0 /run/overlayfs` is ineffective in the initramfs.

While for non-volatile upper overlay filesystem targets, the command
`chcon -t root_t / /run/overlayfs /run/ovlwork`
issued from the dracut pre-pivot hook, overlayfs-pre-pivot-actions.sh, is effective,
the volatile tmpfs /run will not accept the label at this point in the boot.

One could provide a customized policy for /run/overlayfs & /run/ovlwork, such as with
`semanage fcontext -a -t root_t -f d '^/run/(overlayfs|ovlwork)$'`,
and after switch-root, systemd will relabel /run to these contexts--but the root / context will remain as tmpfs_t.

Supplying systemd with an extra relabel list as with
`echo "/" > /run/systemd/relabel-extra.d/root_t.relabel`
will work, but currently, systemd relabels the whole directory tree, so this would cause an extended delay on ever volatile overlay boot.
(One wishes that there was a directive modifier, such as @/, to relabel only the directory itself and not the contents.)

For now, an expedient fix for the mislabeling may be to provide the init system (systemd in Fedora) with a service to run soon after switch-root:

Provide `dracut/modules.d/70overlayfs/overlayfs-root_t.service` as the following:
    [Unit]
    Description=SELinux root contexts for virtual OverlayFS upper directories
    DefaultDependencies=no
    ConditionPathExists=/sys/fs/selinux
    ConditionPathExists=/run/overlayfs
    ConditionPathIsSymbolicLink=!/run/overlayfs
    Before=local-fs-pre.target first-boot-complete.target

[Service]
    Type=oneshot
    ExecStart=/usr/bin/overlayfs-root_t.sh

[Install]
    WantedBy=sysinit.target

And provide `dracut/modules.d/70overlayfs/overlayfs-root_t.service` as below:
    #!/bin/sh -x

# Change SELinux context type for root & OverlayFS directories on virtual filesystems.
    chcon -t root_t / /run/overlayfs /run/ovlwork

# Restore contexts changed in overlayfs-pre-pivot-actions.sh, which added links
    #  to /usr/lib/systemd/system in the OverlayFS.
    chcon -t usr_t /usr
    chcon -t lib_t /usr/lib /usr/lib/systemd
    chcon -t bin_t /usr/bin /usr/bin/overlayfs-root_t.sh
    chcon -h -t systemd_unit_file_t /usr/lib/systemd/system \
         /usr/lib/systemd/system/overlayfs-root_t.service \
         /usr/lib/systemd/system/local-fs-pre.target.wants \
         /usr/lib/systemd/system/local-fs-pre.target.wants/overlayfs-root_t.service

In `dracut/modules.d/70overlayfs/module-setup.sh` include these install instructions:
    inst_script "$moddir"/overlayfs-root_t.sh /sbin/overlayfs-root_t.sh
    inst_simple "$moddir"/overlayfs-root_t.service "$systemdutildir"/system/overlayfs-root_t.service

Then in `dracut/modules.d/70overlayfs/overlayfs-pre-pivot-actions.sh` issue these commands if a volatile overlay is being booted:
    cp /usr/lib/systemd/system/overlayfs-root_t.service "$NEWROOT"/usr/lib/systemd/system/overlayfs-root_t.service
    cp /usr/bin/overlayfs-root_t.sh "$NEWROOT"/usr/bin/overlayfs-root_t.sh
    mkdir "$NEWROOT"/usr/lib/systemd/system/local-fs-pre.target.wants
    ln -sf ../overlayfs-root_t.service \
        "$NEWROOT"/usr/lib/systemd/system/local-fs-pre.target.wants/overlayfs-root_t.service

See https://github.com/FGrose/dracut-ng/commit/0de63c0a695f10b7a110ca3f781e308c1...

Comments? Is there a more robust remedy?