Re: Incorrect contexts in /run revisited

I think that the call to init_daemon_pidfile is probably missing a context
definition in the .fc file for those locations that checkpath is enforcing.

You can file a bug for this (a single bug is fine, we don't need one for
every missing definition). We will upstream it when  appropriate.

Wkr
  Sven
On Aug 16, 2014 9:46 PM, "Ben Pritchard" <[email protected]> wrote:

> Hello all
>
> In March, I reported some issues with SELinux contexts in /run. (I seem
> to have misplaced the email -- archive at
> http://article.gmane.org/gmane.linux.gentoo.hardened/6180).
>
> It look like Sven added the functionality a few months ago, and it is
> available in version 2.20140311-r5 (currently ~arch).
>
> Note 1: There are a few pacakges that need this implemented. Fail2ban
> is one on my machine. Should I file a bug report (probably against
> sec-policy/selinux-fail2ban)?
>
> Note 2: There's possibly a bug in the new tmpfiles module
> (policy/modules/system/tmpfiles.fc). I'm not so sure /lib/rc/bin/checkpath
> should have context tmpfiles_exec_t. Again, this seems to make several
> directories (and maybe files) in /run have context var_run_t.
>
> What I think is happening is that init_daemon_pid_file() only allows
> transitions for the initrc_t domain, and checkpath is no longer running in
> that domain. Therefore, the file transition from var_run_t to whatever
> type is specified as the first argument in init_daemon_pid_file is
> not done.
>
> Changing the context of /lib/rc/bin/checkpath to bin_t makes many more
> of the files in /run have the correct context again on boot.
>
> (perhaps this belongs on the selinux mailing list?)
>
> Thanks
>
> --
> Ben Pritchard
>
>
>
>