Why do matchpathcon and restorecon ignore the user context by default?
Daniel J Walsh
dwalsh at redhat.com
Wed Jul 31 21:18:27 UTC 2013
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 07/31/2013 03:13 PM, Bram Mertens wrote:
> On Wed, Jul 31, 2013 at 7:11 PM, Daniel J Walsh <dwalsh at redhat.com> wrote:
> On 07/31/2013 12:55 PM, Bram Mertens wrote:
>>>> Hi,
>>>>
>>>> I have just lost several hours trying to figure out why I was unable
>>>> to deploy a file from a configuration channel in our satellite server
>>>> to a RHEL6 box while it deployed perfectly to a RHEL5 box.
>>>>
>>>> I finally tracked it down to the fact that the user context was set
>>>> to unconfined_u while the rest of the context was set correctly.
>>>>
>>>> On RHEL5 rhncfg-client get worked flawlessly and deployed the file
>>>> with a *different* user context (system_u) without complaining. On
>>>> RHEL6 chncfg-client crashed complaining about the SElinux context -
>>>> which differed only in the user context.
>>>>
>>>> Here's what I found (I also posted this as a follow up on the
>>>> rhn-satellite mailing list):
>>>>
>>>> I see some very strange behaviour of SELinux on this RHEL6 box.
>>>>
>>>> on RHEL5 the following works as expected:
>>>>
>>>> The default SELinux security context for /etc/sssd/sssd.conf is:
>>>> [mertensb at testadintegration01 ~]$ sudo /usr/sbin/matchpathcon
>>>> /etc/sssd/sssd.conf /etc/sssd/sssd.conf system_u:object_r:etc_t
>>>>
>>>> Which is also what is currently applied:
>>>> [mertensb at testadintegration01 ~]$ sudo ls -lZ /etc/sssd/sssd.conf
>>>> -rw------- root root system_u:object_r:etc_t
>>>> /etc/sssd/sssd.conf
>>>>
>>>> So matchpathcon is able to verify the context.
>>>> [mertensb at testadintegration01 ~]$ sudo /usr/sbin/matchpathcon -V
>>>> /etc/sssd/sssd.conf /etc/sssd/sssd.conf verified.
>>>>
>>>> Testing a randomn other file to verify that matchpathcon works:
>>>> [mertensb at testadintegration01 ~]$ touch /tmp/proftpd
>>>> [mertensb at testadintegration01 ~]$ sudo ls -lZ /tmp/proftpd
>>>> -rw-rw-r-- mertensb mertensb user_u:object_r:tmp_t
>>>> /tmp/proftpd [mertensb at testadintegration01 ~]$ sudo mv /tmp/proftpd
>>>> /etc/cron.monthly/proftpd [mertensb at testadintegration01 ~]$ sudo ls
>>>> -lZ /etc/cron.monthly/proftpd -rw-rw-r-- mertensb mertensb
>>>> user_u:object_r:tmp_t /etc/cron.monthly/proftpd
>>>> [mertensb at testadintegration01 ~]$ sudo /usr/sbin/matchpathcon
>>>> /etc/cron.monthly/proftpd /etc/cron.monthly/proftpd
>>>> system_u:object_r:ftpd_exec_t [mertensb at testadintegration01 ~]$ sudo
>>>> /usr/sbin/matchpathcon -V /etc/cron.monthly/proftpd
>>>> /etc/cron.monthly/proftpd has context user_u:object_r:tmp_t, should
>>>> be system_u:object_r:ftpd_exec_t
>>>>
>>>> But on the RHEL6 machine I get: [mertensb at defrltot002 ~]$ sudo ls
>>>> -lZ /etc/sssd/sssd.conf -rw-------. root root
>>>> unconfined_u:object_r:etc_t:s0 /etc/sssd/sssd.conf
>>>> [mertensb at defrltot002 ~]$ sudo /usr/sbin/matchpathcon
>>>> /etc/sssd/sssd.conf /etc/sssd/sssd.conf
>>>> system_u:object_r:etc_t:s0 [mertensb at defrltot002 ~]$ sudo
>>>> /usr/sbin/matchpathcon -V /etc/sssd/sssd.conf /etc/sssd/sssd.conf
>>>> verified.
>>>>
>>>> Repeating my test of matchpathcon: [mertensb at defrltot002 ~]$ touch
>>>> /tmp/proftpd [mertensb at defrltot002 ~]$ sudo mv /tmp/proftpd
>>>> /etc/cron.monthly/proftpd [mertensb at defrltot002 ~]$ sudo ls -lZ
>>>> /etc/cron.monthly/proftpd -rw-r--r--. mertensb ISOP
>>>> unconfined_u:object_r:user_ tmp_t:s0 /etc/cron.monthly/proftpd
>>>> [mertensb at defrltot002 ~]$ sudo /usr/sbin/matchpathcon
>>>> /etc/cron.monthly/proftpd /etc/cron.monthly/proftpd
>>>> system_u:object_r:ftpd_exec_t:s0 [mertensb at defrltot002 ~]$ sudo
>>>> /usr/sbin/matchpathcon -V /etc/cron.monthly/proftpd
>>>> /etc/cron.monthly/proftpd has context
>>>> unconfined_u:object_r:user_tmp_t:s0, should be
>>>> system_u:object_r:ftpd_exec_t:s0
>>>>
>>>> Both have the same sssd SELinux policy loaded: RHEL5:
>>>> [mertensb at testadintegration01 ~]$ sudo /usr/sbin/semodule -l|grep
>>>> sssd sssd 1.0.2 RHEL6: [mertensb at defrltot002 ~]$ sudo
>>>> /usr/sbin/semodule -l|grep sssd sssd 1.0.2
>>>>
>>>> Digging further I found out that if only the user context is
>>>> different matchpathcon returns OK. See
>>>> http://manpages.ubuntu.com/manpages/karmic/man3/matchpathcon.3.html
>>>>
>>>> I also found a post on this list indicating that restorecon has a
>>>> forece option to make it set the user context which it doesn't do by
>>>> default:
>>>> http://fedora.12.x6.nabble.com/restorecon-isn-t-restoring-what-matchpathcon-shows-td2645478.html
>>>>
>>>>
>>>>
So why isn't the user context set/reset by default? After all it clearly
>>>> leaves the system in a broken state.
>>>>
>>>> And why doesn't matchpathcon have a similar force option to make it
>>>> check the entire context?
>>>>
>>>> Thanks in advance.
>>>>
>>>> Bram Mertens -- selinux mailing list selinux at lists.fedoraproject.org
>>>> https://admin.fedoraproject.org/mailman/listinfo/selinux
>>>>
>
> Well the user component is ignored on almost every SELinux System and all
> that are shipped with policy from Red Hat.
>
> The first couple of paragraphs of
>
> http://danwalsh.livejournal.com/63586.html
>
> explain this.
>
> restorecon main goal is to fix the "type" portion of the SELinux label and
> not to touch the User component or the MLS field unless you specify -F.
>
>
>
>
>
>
>
> So does that mean that rhncfg-client is doing something wrong when it fails
> on this? Should I then raise this as an issue for rhncfg-client?
>
> Regards
>
> Bram -- selinux mailing list selinux at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/selinux
>
Yes it should just use restorecon and not try to be smart with matchpathcon,
If it wants to force the context then use the -f option.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlH5fyMACgkQrlYvE4MpobO8UwCg4naOAvn8svIWNPPpCrFeD/tr
E6AAnR7NQbCLOnNSB7hbbR7mhpQwQ48v
=YHCy
-----END PGP SIGNATURE-----
More information about the selinux
mailing list