[BUG] Hauler cannot load copy images to registry from RHEL8 system when $HOME has noexec flag set

[NullOranje]

Environmental Info:

• Linux 4.18.0-425.3.1.el8.x86_64 Update Vagrantfile for (hacky) air-gapped local environment #1 SMP Fri Sep 30 11:45:06 EDT 2022 x86_64 x86_64 x86_64 GNU/Linux

Hauler Version:

• GitVersion: 1.0.3
• GitCommit: 7fc24f6
• GitTreeState: clean

Describe the Bug:

• When attempting to run hauler store copy <registry> on a RHEL8 STIG'd system, hauler throws an error ERR fork/exec /home/<user>/.hauler/cosign: operation not permitted"

Steps to Reproduce:

• Copy Hauler to any authorized path (without noexec flag set) (e.g., /usr/local/bin)
• Load images into local airgapped store: hauler store load <archive>
• Run hauler store copy registry://<registry>
• Observe the error above

Expected Behavior:

• Command should run to completion.

Actual Behavior:

• cosign attempts to run from inside ${HOME}/.hauler/cosign. This is unauthorized behavior according to DISA and blocked.

Additional Context:

• Need to be able to specify another path or, preferably, an external cosign binary that is pre-positioned

[zackbradys]

hey @NullOranje, thank you for submitting this issue! we will begin testing and validating it and let you know our way forward. please let us know if there is any additional information.

[dweomer]

Dunno if such is STIG compliant but a workaround might be to setup a $HOME/.config/systemd/hauler.mount unit that sets up a bind-mount for $HOME/.hauler to something like /var${HOME}/.hauler or something similar?

[NullOranje]

I did something similar. I moved the bin to an allowed path and set a symlink ${HOME}/.hauler/cosign to the binary. It seems to be workable solution for now.

[jaredpricedev]

I have attempted the workaround for this by trying to do a symbolic link from a lvm that does not have noexec set but I am still getting this error.

I also attempted to make the serviced with the following code:

[Unit]
Description=Data mount

[Mount]
What=/var/root/.hauler
Where=/root/.hauler
Type=none
Options=bind

[Install]
WantedBy=multi-user.target

I have turned off selinux and fips to test if that was getting in the way as well and it was still not working. I don't mind looking into resolving if this is not being currently worked. I have had no issues running the binary directly when it is in the /root/.hauler/cosign.

[zackbradys]

Hey @NullOranje, that is what most customers are doing when running into this issue. Thanks for your patience on this.

I did something similar. I moved the bin to an allowed path and set a symlink ${HOME}/.hauler/cosign to the binary. It seems to be workable solution for now.

[zackbradys]

Hey @jaredpricedev! If you have the time, then it would be appreciated!

We were discussing implementing a similar function to the tempdir directory override that was implemented a few versions ago so users can use the flag --tempdir/-t and change the default temporary directory so creating something similar for the configuration directory would be a good starting point. Possibly --configdir/-c?

https://github.com/hauler-dev/hauler/blob/main/cmd/hauler/cli/store/load.go

[dweomer]

Note

If you are attempting a work-around until a fix is in place, any alternate location you have setup will need to be:

• on a filesystem sans noexec
• on a location your user can write to

Note

If SELinux is enabled and enforced you will want the .hauler directory to have the bin_t type label or similar.

If the filesystem that /home/<user>/.hauler exists on is not mounted noexec and the location is writable by you but you are still seeing permission denied on an SELinux-enforcing system, the root user should be able to inspect the audit log to determine if that is indeed the case, e.g.:

ausearch -m avc -ts recent | grep -E 'hauler|cosign'

[zackbradys]

Hey @NullOranje @jaredpricedev... please check out the recent PR and let us know if it looks good. If you have time to test it, please pass along any feedback!

git clone https://github.com/zackbradys/hauler.git && cd hauler && make build

[zackbradys]

Hey @NullOranje and @jaredpricedev... please let us know if you encounter any issues with v1.1.1-dev.1!