Mailing List Archive: Incorrect contexts in /run

Hello

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

#output from restorcon -rv /run
restorecon: Warning no default label for /run/sshd.pid
restorecon: Warning no default label for /run/privoxy-tor.pid
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/fail2ban context system_u:object_r:initrc_var_run_t->system_u:object_r:fail2ban_var_run_t
restorecon reset /run/fail2ban/fail2ban.sock context system_u:object_r:initrc_var_run_t->system_u:object_r:fail2ban_var_run_t
restorecon reset /run/fail2ban/fail2ban.pid context system_u:object_r:initrc_var_run_t->system_u:object_r:fail2ban_var_run_t
restorecon reset /run/syslog-ng.ctl context system_u:object_r:devlog_t->system_u:object_r:syslogd_var_run_t
restorecon: Warning no default label for /run/dbus.pid
restorecon reset /run/sepermit context system_u:object_r:initrc_var_run_t->system_u:object_r:pam_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
restorecon reset /run/lvm context system_u:object_r:initrc_var_run_t->system_u:object_r:var_run_t
restorecon reset /run/saslauthd context system_u:object_r:initrc_var_run_t->system_u:object_r:var_run_t
restorecon reset /run/lock/lvm context system_u:object_r:var_lock_t->system_u:object_r:lvm_lock_t

#from the mount command:
tmpfs on /run type tmpfs (rw,rootcontext=system_u:object_r:var_run_t,seclabel,nosuid,nodev,relatime,mode=755)

Thanks
--
Ben Pritchard
ben@bennyp.org

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