Fedora instructions show that we create an nspawn container in /var/lib/machines, install a container there, and then have it selinux labeled.
Question - is it imperative to have your nspawn container machine be in the /var/lib/machines folder to have selinux labels of the container to be always properly maintained during container’s operation?
I’m still not sure how selinux works with nspawn exactly. It’s impossible to turn on selinux from within nspawn containers, even if they are booted. So selinux is applied from the host side? Using which policy? What are the requirements for the containers in this regard?
thirst, I’m not so familiar with nspawn.
Under Fedora I personally use Podman for using container.
You could do something like this and check if it works
chcon -Rv --reference=/var/lib/machines /your/path/you/want/to/use
This copies the SELinux permission of “/var/lib/machines” to the path you want to use.
Then you could try to check if there still are problems with commands like this:
ausearch -m AVC,USER_AVC,SELINUX_ERR,USER_SELINUX_ERR -ts today
As time marker, you can use one of:
[ now | recent | this-hour | boot | today | yesterday | this-week | week-ago | this-month | this-year ]
Oh, I labeled the container initially after setting up just fine. My question is: is that all I need to do? Do all newly created files within the container as a result of its inner operation propagate correct labels regardless of where the container is stored and what it does?
That’s a good question. Have you tested? This might be one way to find it out.
My personal guess is that it might work, since it already does work under the default path, right?
However, the solution above is not persistent.
If you execute a restorecon command, the SELinux permission might get reset to the default values.
So you would need to make it persistent using the semanage command.
First check out the original permissions using
ls -ahlZ /var/lib/machines/
then set it via (for example, please use the correct types)
semanage fcontext -a -t systemd_machined_var_lib_t '/your/custom/path(/.*)?'
Now it should be permanent. But this only applies for the SELinux part.
Set it by
restorecon -R -v /your/custom/path
Nspawn should set new files with correct permissions itself.
As far as I know SELinux does not set them automatically, it just verifies them, allows or disallows execution. (If your question was into this direction)
Thanks, this is sort of what I was wondering about. So I guess my key 100 million dollar question is that it matters if my containers are in a folder with the -t systemd_machined_var_lib_t for SELinux to secure them properly when systemd-nspawn is run on that container??
`Example 2. Build and boot a minimal Fedora distribution in a
# dnf -y --releasever=39 --installroot=/home/<User>/Containers/Contain \
--repo=fedora --repo=updates --setopt=install_weak_deps=False install \
passwd dnf fedora-release vim-minimal util-linux systemd systemd-networkd
# systemd-nspawn -bD /home/<User>/Containers/Contain`
This is a flash back for me, Back in my day we installed it anywhere we wanted Here is a video of how we used to do it 9yrs ago and is still relevant.
At 0:22 He goes into the install of the container in a different root. Ignore the use of yum here, dnf will do the trick for this.
Basically installing the root file system somewhere else and adding the new SELinux labels so as not to interfere with the host file system. At 2:35 Seth discusses the reasons why he has a rule set up for this.
edit: I reviewed some notes and the last time i used the SELinux sandbox commands I used
sandbox_web_t if that is not already apparent.
This is how we used to install debian on fedora to run spotify back then. . .
I hope this helps and does not take you off track.