These are VERY nice changes, automating what I've been doing manually.
An observation: the package 'install' process has gotten much better with file contexts.
Any thoughts on automating the assignment of file contexts to the files created by package scripts (e.g., /boot/grub/grub.conf, depmod files, /etc/selinux/config, ...)? Would be nice to have a 'SELinux package description' that describes the package's desired/default contexts. That would allow inspection prior to install, tools to check consistency with installed file_contexts, etc. 'rpm -q --filecontext' is almost it. Any way to add the other stuff to it, or something like it?
tom
[Sorry if this is old hat....]
Dan Walsh wrote:
Setfiles and restorecon have a new qualifier (-o filename) which will record the file paths of any files that the tools find with the incorrect security context. So if you run setfiles -n -v -o /tmp/badfilecontexts, you would have a report and a file with all the paths of files with bad file contexts. If everything looks ok, you could run restorecon -f /tmp/badfilecontexts and clean them up quickly.
Tom London wrote:
These are VERY nice changes, automating what I've been doing manually.
An observation: the package 'install' process has gotten much better with file contexts.
Well, that isn't a complement to rpm, but rather that policy is changing much more carefully imho.
Any thoughts on automating the assignment of file contexts to the files created by package scripts (e.g., /boot/grub/grub.conf, depmod files, /etc/selinux/config, ...)? Would be nice to have a 'SELinux package description' that describes the package's desired/default contexts. That would allow inspection prior to install, tools to check consistency with installed file_contexts, etc. 'rpm -q --filecontext' is almost it. Any way to add the other stuff to it, or something like it?
Sure there's been thought, as well as a request for a syntax marker within package headers for files generated as a side effect of doing a package install.
This is not going to work mostly because the side effect file probably does not exist when a package is installed, and hence there's no way set the file context from within the installer because the file is not being \created by the installer.
The deeper problem is not the handful (perhaps big) of files that are created as a side effect of installing a package, but rather files in /home which are not (and will never be) in a package at all.
So the current thought is to attempt to set file contexts not only when installing a package, but also through other means, like a cron script.
The slocate database has been suggested as a means to enumerate all paths for appling the existing file context regexes. That will work, but will probably (I haven't checked yet) the file type as well.
73 de Jeff
selinux@lists.fedoraproject.org
-
Jeff Johnson -
Tom London