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
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.
building 2.02.23-1 with this change
*** Bug 234189 has been marked as a duplicate of this bug. ***