Re: 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(a)redhat.com&gt; 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(a)redhat.com&gt; 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@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@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@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@testadintegration01 ~]$ touch /tmp/proftpd
> >>>> [mertensb@testadintegration01 ~]$ sudo ls -lZ /tmp/proftpd
> >>>> -rw-rw-r-- mertensb mertensb user_u:object_r:tmp_t
> >>>> /tmp/proftpd [mertensb@testadintegration01 ~]$ sudo mv /tmp/proftpd
> >>>> /etc/cron.monthly/proftpd [mertensb@testadintegration01 ~]$ sudo ls
> >>>> -lZ /etc/cron.monthly/proftpd -rw-rw-r--  mertensb mertensb
> >>>> user_u:object_r:tmp_t /etc/cron.monthly/proftpd
> >>>> [mertensb@testadintegration01 ~]$ sudo /usr/sbin/matchpathcon
> >>>> /etc/cron.monthly/proftpd /etc/cron.monthly/proftpd
> >>>> system_u:object_r:ftpd_exec_t [mertensb@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@defrltot002 ~]$ sudo ls
> >>>> -lZ /etc/sssd/sssd.conf -rw-------. root root
> >>>> unconfined_u:object_r:etc_t:s0 /etc/sssd/sssd.conf
> >>>> [mertensb@defrltot002 ~]$ sudo  /usr/sbin/matchpathcon
> >>>> /etc/sssd/sssd.conf /etc/sssd/sssd.conf
> >>>> system_u:object_r:etc_t:s0 [mertensb@defrltot002 ~]$ sudo
> >>>> /usr/sbin/matchpathcon -V /etc/sssd/sssd.conf /etc/sssd/sssd.conf
> >>>> verified.
> >>>>
> >>>> Repeating my test of matchpathcon: [mertensb@defrltot002 ~]$ touch
> >>>> /tmp/proftpd [mertensb@defrltot002 ~]$ sudo mv /tmp/proftpd
> >>>> /etc/cron.monthly/proftpd [mertensb@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@defrltot002 ~]$ sudo /usr/sbin/matchpathcon
> >>>> /etc/cron.monthly/proftpd /etc/cron.monthly/proftpd
> >>>> system_u:object_r:ftpd_exec_t:s0 [mertensb@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@testadintegration01 ~]$ sudo /usr/sbin/semodule -l|grep
> >>>> sssd sssd 1.0.2 RHEL6: [mertensb@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-matchpathc...
> >>>>
> >>>>
> >>>>
>  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(a)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(a)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