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

[Bram Mertens]

On Wed, Jul 31, 2013 at 7:11 PM, Daniel J Walsh <dwalsh at redhat.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> 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.
>
>
>
>
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.14 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlH5RVsACgkQrlYvE4MpobPujACgyNguC2utjf+9Mkd7RYBaifTW
> eEwAoN7+WmSqrGGvFf4GZYK4uVJlEoHC
> =/c3M
> -----END PGP SIGNATURE-----

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