Why do matchpathcon and restorecon ignore the user context by default? - solved

[Bram Mertens]

On Wed, Jul 31, 2013 at 11:18 PM, Daniel J Walsh <dwalsh at redhat.com> wrote:
> -----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-----

One final update in case anyone runs into this as well.

The problem was not caused by the incorrect user label but because the
service mcstrans wasn't running.
It appears that this service is responsible for handling these user
label corrections.

So the solution to the above stack trace is to start the mcstrans service.

When the mcstrans service is running the user context is automatically
corrected.

HTH

Bram