On Sun, Mar 02, 2014 at 04:36:23PM -0500, Ben Pritchard wrote:
> I have a few files/directories in /run (or /var/run) that do not have the
> correct selinux contexts. Notably, files belonging to samba and fail2ban,
> but there may be others.
>
> I thought this might be related to the /run migration bug (424173) but
> it seems to restore to the correct contexts, just that the files are not
> created with the correct contexts. How are the contexts of these files
> usually managed?
>
>
> #output from matchpathcon:
> /run/dbus.pid has context system_u:object_r:system_dbusd_var_run_t, should be
> <<none>>
> /run/fail2ban has context system_u:object_r:initrc_var_run_t, should be
> system_u:object_r:fail2ban_var_run_t
> /run/lvm has context system_u:object_r:initrc_var_run_t, should be
> system_u:object_r:var_run_t
> /run/ntpd.pid has context system_u:object_r:initrc_var_run_t, should be
> system_u:object_r:ntpd_var_run_t
> /run/privoxy-tor.pid has context system_u:object_r:privoxy_var_run_t, should
> be <<none>>
> /run/samba has context system_u:object_r:initrc_var_run_t, should be
> system_u:object_r:smbd_var_run_t
> /run/saslauthd has context system_u:object_r:initrc_var_run_t, should be
> system_u:object_r:var_run_t
> /run/sepermit has context system_u:object_r:initrc_var_run_t, should be
> system_u:object_r:pam_var_run_t
> /run/sshd.pid has context system_u:object_r:sshd_var_run_t, should be <<none>>
> /run/syslog-ng.ctl has context system_u:object_r:devlog_t, should be
> system_u:object_r:syslogd_var_run_t
The matchpathcon and restorecon actions should be the same: matchpathcon
tells the user what the value should be, restorecon applies this value.
When matchpathcon sais that a label should be <<none>> then no specific
action is taken. This is usually the case for files that get a file context
assigned by the process that creates the file, and which might be different
depending on circumstances. Or in other words, SELinux keeps the label
as-is, even during a restorecon operation.
For instance:
# matchpathcon
> /run/ntpd.pid has context system_u:object_r:initrc_var_run_t, should be
> system_u:object_r:ntpd_var_run_t
> /run/samba has context system_u:object_r:initrc_var_run_t, should be
> system_u:object_r:smbd_var_run_t
# restorecon
> restorecon reset /run/ntpd.pid context
> system_u:object_r:initrc_var_run_t->system_u:object_r:ntpd_var_run_t
> restorecon reset /run/samba context
> system_u:object_r:initrc_var_run_t->system_u:object_r:smbd_var_run_t
> restorecon reset /run/samba/nmbd.pid context
> system_u:object_r:initrc_var_run_t->system_u:object_r:nmbd_var_run_t
> restorecon reset /run/samba/smbd.pid context
> system_u:object_r:initrc_var_run_t->system_u:object_r:smbd_var_run_t
In order to have the files immediately with the right context, we need to
find out which process (actually, which SELinux domain) is responsible for
creating the files in the first place (and thus having the files stored with
a particular label).
For most of the files, this is easy to deduce.
For instance, /run/ntpd.pid got label initrc_var_run_t, so it's most likely
initrc_t (the domain used for init scripts) that created the PID file. And
if I'd take a long guess, it would be /etc/init.d/ntpd ;-)
In order to fix this, we need to add in a statement that equals to:
#v+
files_pid_filetrans(initrc_t, ntpd_var_run_t, file, "ntpd.pid")
#v-
Sadly, this statement calls two types not part of the same module (initrc_t
is of the "init" module while ntpd_var_run_t is of the "ntp" module).
Coding-style wise, this is not allowed, so we need to seek (or write)
another statement that only calls types of the same module.
For directories, we created an "init_daemon_run_dir" call. It looks like we
might need to introduce a similar one for files, namely
"init_daemon_run_file". Then the call would be (inside ntp.te):
#v+
init_daemon_run_file(ntpd_var_run_t, "ntpd.pid")
#v-
For the samba directory, we can already use the init_daemon_run_dir() call,
as /run/samba has context initrc_var_run_t (thus also created most likely by
the smb* or other samba related init scripts).
I'll put your mail in a bugreport and might even work on it this evening
(depending on available time). I'll get back to you when the necessary
commits have occurred ;-)
Wkr,
Sven Vermeulen
