1. See if the file context specification from the various modules in refpolicy contrib match the locations of the corresponding packages that your distribution uses.
Here is how i do that on Fedora:
I basically check each modules file context files.
Find which package installs the executable file, either with the full path or if my package manager cannot find that using a wild card:
or if it cannot find that:
yum whatprovides /usr/sbin/someapp
yum whatprovides *\someapp
Then you should figure out which (applicable) locations that package installs.
Applicable locations are among others:
/etc/someapp /etc/sysconfig/someapp /etc/default/someapp /var/lib/someapp /var/log/someapp /var/spool/someapp /etc/init.d/someapp /etc/rc.d/init.d/someapp /var/run/someapp /var/cache
In Fedora i use the handy repoquery tool for that. This tool allows me to list the files that a specificied package installs without me actually having to install the package
Example:
repoquery -ql someapp | less
Labeling files properly is very important for SELinux operation and so you can improve your distributions SELinux experience by making use applicable files and locations are labeled correctly by fixing or adding the appropriate file context specification.
2. Somewhat related to (1): label service etc files with a declared private type for etc files and allow the service to read files it owns with the private type, then also allow the "service"_admin() to find and manage content with that type.
In the past we only use to label service etc files with a private"files config file" private type if the file has sensitive information.
Later we came up with an idea to confine root using "service"_admin interfaces that give the caller access to manage a particular service and its files.
However we do not want to give the "service"_admin access to manage generic etc_t files since that will allow the process to manage things it shouldnt, instead of just the configuration files for the service that the caller is allowed to manage.
So we need to find each config file a confined service owns label that with a declared "files_config_file" file type, allow the owning service to read applicable content with that type and allow the service admin to get to and manage content with that type.
You can use the method of (1) to find which etc files a package installs where
Then if needed declare a new files_config_file type
type someapp_conf_t;
files_config_file(someapp_conf_t)
Then make sure the file or directory is labeled correctly in the file context file. Some examples:
Single configuration file:
/etc/someapp\.conf -- gen_context(system_u:object_r:someapp_conf_t,s0)
A configuration directory and all its contents:
/etc/someapp(/.*)? gen_context(system_u:object_r:someapp_conf_t,s0)
Then allow the service domain type to read the content:
in case of a single file:
allow someapp_t someapp_conf_t:file read_file_perms;
in case of a directories and its contents:
read_files_pattern(someapp_t, someapp_conf_t, someapp_conf_t)
If your service domain type is not already allowed to read generic etc_t files (e.g. if it does not have a rule similar to for example: files_read_etc_files(someapp_t) then you will also need to allow the service domain type to traverse etc_t directories so that it can actually get to there:
files_search_etc(someapp_t)
If the module has a service admin interface, for example someapp_admin in the someapp.if interface file, then add the rules that will allow the caller to get to and manage content with the new type:
a. Import the type by adding for example;
type someapp_conf_t;
to the existing "gen_require(`')" block on top of the interface.
b. Add the rules to allow caller to get to and manage the content with the new type , for example:
files_search_etc($1)
admin_pattern($1, someapp_conf_t)
Note: also consider environment files in /etc/sysconfig. We would want the service administrator to be able to manage those as well.
If you are unsure about some specifics then look into existing source policy modules. Much efford goes into writing these modules as consistently as possible.
This allows you to see patterns easily and will help you read the policy.
