I’m trying to set up a CoreOS VM with a mounted in volume (using virtiofs in case it matters, with extended attributes enabled of course) for Podman containers to use as storage, and I’m struggling to get the SELinux labels applied correctly. The volume supports extended attributes and I can manually set SELinux labels on it just fine, but labels are not automatically applied on file creation, which is leading to permissions issues for containers that are using the volume.
I’m mounting the volume with a systemd mount unit, I’ve tried Options=rw,relatime and Options=rw,relatime,defcontext="system_u:object_r:container_file_t:s0" and neither work (setting defcontext doesn’t do anything for some reason). I’ve tried setting file contexts both using semanage fcontext and by manually editing file_contexts.local (trying to minimise the need to overlay extra packages - tried manual editing on a system without semanage on it) and it kind of worked once but after a reboot stopped working again, and subsequent attempts at doing the exact same thing don’t work. What’s strange though is that if I set a default context with semanage fcontext and then run restorecon on it all the labels get set correctly, but only if I run restorecon - even new files created in that folder don’t get the context applied until I run restorecon.
What am I missing? Surely if it’s set up so that restorecon is setting the labels correctly then new files should also get those same labels by default?
You can set the default security context for unlabeled files using
defcontext= option. This overrides the value set for unlabeled files
in the policy and requires a filesystem that supports xattr labeling.
which I interpret as the defcontext= only aplies to files which doesn’t already have a defined context. When you create a new file, the file inherits the selinux context from the directory, unless there is a relevant “typetransition” rule in place.
Sure, that describes what should happen, but that’s not what’s actually happening. What’s actually happening is that I can go into a folder with the correct system_u:object_r:container_file_t:s0 context, create a new file, and the new file for some reason is unlabelled. I can then run restorecon <new file> and the file then gets labelled correctly, demonstrating that it should be getting labelled but isn’t. defcontext= makes no difference - with or without it, new files don’t get labelled, at all, without manual intervention.
Gahh, finally found the problem. Turns out the virtiofsd instructions are misleading at best when it comes to SELinux labelling - they strongly imply that you can map guest SELinux labels to user attributes on the host without setting the security label flag (there’s one section where it even suggests doing this specifically to not run the server side binary with enough permissions to set security labels) - this seems to be completely false. Despite running with the exact mapping in the instructions (and despite SELinux labels seeming to work when set manually) retrying everything with --security-label also set suddenly everything works
