Description of problem: SELinux protects certain Files/Directories against tampering by compromised applications. The way it does this is through the labeling of files. If I file is removed and recreated in a directory, by default it addopts the label of the directory. We can write transition rules in SELinux that say when a process labeled xyz_t creates a file in lvm_etc_t it should get labeled lvm_metadata_t, but if we do not cover all of the applications that create this file, the file will get created with the wrong context. This is happening with /etc/lvm/.cache file. If this file was moved to /var/cache/lvm/ or /etc/lvm/cache/ We could then label the directory lvm_metadata_t and all files created in the directory would have the correct context.
Only lvm tools should be touching that file. Should the tools be calling set_selinux_context() like they do elsewhere if they create the file? [/var is not necessarily available when this runs while booting whereas /etc is.] Anyway, I'll consider ways of separating it from the config files: people *are* free to create additional config files in that directory with names of their choice (matching a pattern), so those files need to inherit the context appropriate for config files. And the .cache file was just a quick 'proof of concept' thing: its format will change and it might get split into several files.
From an SELinux point of view the easiest thing is to put it in a subdirectory. /etc/lvm/cache would be fine. So readonly config files would go in /etc/lvm and read/write files in /etc/lvm/cache. Or you could name it what ever you want. Then we label the files in /etc/lvm lvm_etc_t and the files in /etc/lvm/cache lvm_cache_t. Adding SELinux awareness to lvm tools is not necessary and would involve giving them additional privs that they do not need now.
OK - I've changed this upstream (to use /etc/lvm/cache/.cache) so it'll get picked up next time I update the package.
Ok I will adjust the selinux-policy package appropriately. Thanks. Dan
building 2.02.23-1 with this change
*** Bug 234189 has been marked as a duplicate of this bug. ***