Bug 1220691

commit ccf623eb506a9eb07ee946b7bdc0fa94b7670e5b
Author: Miroslav Grepl <mgrepl>
Date:   Tue May 19 08:54:27 2015 +0200

    Add labeling for /usr/sbin/kpropd.

The incremental propagation for krb5 stopped working with this new policy. It still working in permissive mode. The following AVC denials blocks the propagation (collected in permissive mode):


ON MASTER:

type=SYSCALL msg=audit(05/22/2015 09:53:25.649:1015) : arch=x86_64 syscall=open success=yes exit=35 a0=0x7f4b8689e430 a1=O_WRONLY|O_CREAT|O_EXCL|O_TRUNC a2=0600 a3=0x65726373662f7274 items=0 ppid=1 pid=18391 auid=root uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=113 comm=kadmind exe=/usr/sbin/kadmind subj=unconfined_u:system_r:kadmind_t:s0 key=(null) 
type=AVC msg=audit(05/22/2015 09:53:25.649:1015) : avc:  denied  { write open } for  pid=18391 comm=kadmind name=kiprop_0 dev=dm-0 ino=1836884 scontext=unconfined_u:system_r:kadmind_t:s0 tcontext=unconfined_u:object_r:krb5kdc_tmp_t:s0 tclass=file 
type=AVC msg=audit(05/22/2015 09:53:25.649:1015) : avc:  denied  { create } for  pid=18391 comm=kadmind name=kiprop_0 scontext=unconfined_u:system_r:kadmind_t:s0 tcontext=unconfined_u:object_r:krb5kdc_tmp_t:s0 tclass=file 


This case is caused IMO by wrong context of kiprop_0.

-rw-------. root root system_u:object_r:krb5_host_rcache_t:s0 /var/tmp/host_0
-rw-------. root root unconfined_u:object_r:kadmind_tmp_t:s0 /var/tmp/kadmin_0
-rw-------. root root unconfined_u:object_r:krb5kdc_tmp_t:s0 /var/tmp/kiprop_0

Since this file is created by kadmind and not krb5kdc it should use the same context as /var/tmp/kadmin_0, i.e. kadmind_tmp_t.


ON SLAVE:


type=SYSCALL msg=audit(05/22/2015 09:53:25.612:907) : arch=x86_64 syscall=connect success=yes exit=0 a0=0x4 a1=0x7fa824876570 a2=0x1c a3=0x7ffc82b22810 items=0 ppid=1 pid=19205 auid=root uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=113 comm=kpropd exe=/usr/sbin/kpropd subj=unconfined_u:system_r:kpropd_t:s0 key=(null) 
type=AVC msg=audit(05/22/2015 09:53:25.612:907) : avc:  denied  { name_connect } for  pid=19205 comm=kpropd dest=272 scontext=unconfined_u:system_r:kpropd_t:s0 tcontext=system_u:object_r:reserved_port_t:s0 tclass=tcp_socket 


There is already a similar policy form kadmind, and I think this should be allowed for kpropd too:

# sesearch -A -C -s kadmind_t -t reserved_port_t -c tcp_socket |grep name_connect
DT allow kadmind_t reserved_port_type : tcp_socket name_connect ; [ allow_ypbind ]

My mistake. I thought that /var/tmp/kiprop_0 is usually created by kpropd, therefore I suggested krb5kdc_tmp_t as a default context.

The following policy change solves the issue; successfully tested in enforcing mode:

# cat kpropd.te 
 policy_module(kpropd,1.0)

require {
       type kpropd_t;
       type reserved_port_t;
       class tcp_socket name_connect;
}
#
# semanage fcontext -a -t kadmind_tmp_t '/var/tmp/kiprop_0'
#

See 

https://bugzilla.redhat.com/show_bug.cgi?id=1210421#c7

>Since this file is created by kadmind and not krb5kdc it should use the same >context as /var/tmp/kadmin_0, i.e. kadmind_tmp_t.

This is about a transition rules. And we have

   type_transition kpropd_t tmp_t : file krb5kdc_tmp_t; 
   type_transition kpropd_t tmp_t : dir krb5kdc_tmp_t;

   type_transition kadmind_t tmp_t : file kadmind_tmp_t; 
   type_transition kadmind_t tmp_t : dir kadmind_tmp_t;

So it does not like it was created by kadmin. Or did you run restorecon on it?

(In reply to Miroslav Grepl from comment #8)
> See 
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1210421#c7
> 
> >Since this file is created by kadmind and not krb5kdc it should use the same >context as /var/tmp/kadmin_0, i.e. kadmind_tmp_t.
> 
> This is about a transition rules. And we have
> 
>    type_transition kpropd_t tmp_t : file krb5kdc_tmp_t; 
>    type_transition kpropd_t tmp_t : dir krb5kdc_tmp_t;
> 
>    type_transition kadmind_t tmp_t : file kadmind_tmp_t; 
>    type_transition kadmind_t tmp_t : dir kadmind_tmp_t;
> 
> So it does not like it was created by kadmin. Or did you run restorecon on
> it?

I did not run restorecon. The daemon kadmind simple tried to create file /var/tmp/kadmin_0, but it was rejected with AVC denial.

The following list was created in permissive mode, I did not touched or labeled these files at all:

-rw-------. root root system_u:object_r:krb5_host_rcache_t:s0 /var/tmp/host_0
-rw-------. root root unconfined_u:object_r:kadmind_tmp_t:s0 /var/tmp/kadmin_0
-rw-------. root root unconfined_u:object_r:krb5kdc_tmp_t:s0 /var/tmp/kiprop_0

Tested with selinux-policy-3.7.19-269.el6

The only AVC denial that appeared (tested in permissive mode):

----
type=SYSCALL msg=audit(05/26/2015 06:42:31.001:260) : arch=x86_64 syscall=connect success=yes exit=0 a0=0x4 a1=0x7fe98dd9fae0 a2=0x1c a3=0x7fffa47dc1f0 items=0 ppid=1 pid=10890 auid=root uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=19 comm=kpropd exe=/usr/sbin/kpropd subj=unconfined_u:system_r:kpropd_t:s0 key=(null) 
type=AVC msg=audit(05/26/2015 06:42:31.001:260) : avc:  denied  { name_connect } for  pid=10890 comm=kpropd dest=272 scontext=unconfined_u:system_r:kpropd_t:s0 tcontext=system_u:object_r:reserved_port_t:s0 tclass=tcp_socket

Is this a default port or did you define it?

No, this is not the default port. It was defined in configuration and I thought it is the default, but it is not. There is no default port defined; without explicitly adding it in configuration the service is not starting at all.
I tried to search for common practices for the port that us used by admins, but have not found anything useful.

But I've tested incremental propagation with the already defined port 754 that is used for "normal" database propagation and it works (I though it will conflicting in krb5, but it is not). Well, works in permissive mode, because there is still this AVC denial logged:


type=SYSCALL msg=audit(06/03/2015 12:40:24.396:230) : arch=x86_64 syscall=connect success=yes exit=0 a0=0x4 a1=0x7f1d0269b430 a2=0x1c a3=0x7ffe29e0de20 items=0 ppid=1 pid=15278 auid=root uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=11 comm=kpropd exe=/usr/sbin/kpropd subj=unconfined_u:system_r:kpropd_t:s0 key=(null) 
type=AVC msg=audit(06/03/2015 12:40:24.396:230) : avc:  denied  { name_connect } for  pid=15278 comm=kpropd dest=754 scontext=unconfined_u:system_r:kpropd_t:s0 tcontext=system_u:object_r:kprop_port_t:s0 tclass=tcp_socket 


So port 754 probably is a better candidate here. Sorry for confusion.

We allow tcp/754 port by default for kpropd.

The test is still not working, because some dontaudit rules, please find the details below:

# rpm -q selinux-policy
selinux-policy-3.7.19-272.el6.noarch
# semodule -DB
# getenforce 
Enforcing
# service kadmin restart
Stopping Kerberos 5 Admin Server: [  OK  ]
Starting Kerberos 5 Admin Server: [  OK  ]
# netstat -putna |grep -e kadmind -e kprop
tcp        0      0 0.0.0.0:464                 0.0.0.0:*                   LISTEN      18604/kadmind       
tcp        0      0 :::464                      :::*                        LISTEN      18604/kadmind       
udp        0      0 0.0.0.0:464                 0.0.0.0:*                               18604/kadmind       
udp        0      0 fe80::d836:d0ff:fe6e:500:464 :::*                                    18604/kadmind       
udp        0      0 2620:52:0:2258:d836:d0ff:464 :::*                                    18604/kadmind       
# ausearch -m avc -ts recent
----
time->Thu Jun  4 08:55:12 2015
type=SYSCALL msg=audit(1433400912.669:1387): arch=c000003e syscall=49 success=no exit=-13 a0=c a1=7ffd3f364b80 a2=10 a3=7ffd3f364a84 items=0 ppid=18602 pid=18603 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=11 comm="kadmind" exe="/usr/sbin/kadmind" subj=unconfined_u:system_r:kadmind_t:s0 key=(null)
type=AVC msg=audit(1433400912.669:1387): avc:  denied  { name_bind } for  pid=18603 comm="kadmind" src=754 scontext=unconfined_u:system_r:kadmind_t:s0 tcontext=system_u:object_r:kprop_port_t:s0 tclass=tcp_socket


Tried the test again in permissive and these AVCs appeared:

# setenforce 0
# semodule -DB
# service kadmin restart
Stopping Kerberos 5 Admin Server: [  OK  ]
Starting Kerberos 5 Admin Server: [  OK  ]
# ausearch -m avc -ts recent
----
time->Thu Jun  4 08:57:54 2015
type=SYSCALL msg=audit(1433401074.531:1390): arch=c000003e syscall=49 success=no exit=-22 a0=c a1=7fff2f6888c0 a2=10 a3=7fff2f688560 items=0 ppid=18632 pid=18633 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=11 comm="kadmind" exe="/usr/sbin/kadmind" subj=unconfined_u:system_r:kadmind_t:s0 key=(null)
type=AVC msg=audit(1433401074.531:1390): avc:  denied  { name_bind } for  pid=18633 comm="kadmind" src=1001 scontext=unconfined_u:system_r:kadmind_t:s0 tcontext=system_u:object_r:hi_reserved_port_t:s0 tclass=tcp_socket
----
time->Thu Jun  4 08:57:54 2015
type=SYSCALL msg=audit(1433401074.530:1389): arch=c000003e syscall=49 success=yes exit=0 a0=c a1=7fff2f688a20 a2=10 a3=7fff2f688924 items=0 ppid=18632 pid=18633 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=11 comm="kadmind" exe="/usr/sbin/kadmind" subj=unconfined_u:system_r:kadmind_t:s0 key=(null)
type=AVC msg=audit(1433401074.530:1389): avc:  denied  { name_bind } for  pid=18633 comm="kadmind" src=754 scontext=unconfined_u:system_r:kadmind_t:s0 tcontext=system_u:object_r:kprop_port_t:s0 tclass=tcp_socket

Could you re-test it with a local policy for

type=AVC msg=audit(1433400912.669:1387): avc:  denied  { name_bind } for  pid=18603 comm="kadmind" src=754 scontext=unconfined_u:system_r:kadmind_t:s0 tcontext=system_u:object_r:kprop_port_t:s0 tclass=tcp_socket

Yes, the test passed with the following policy:
# cat name_bind_allow.te
policy_module(name_bind_allow,1.0)

require {
       type kadmind_t;
       type kprop_port_t;
       class tcp_socket name_bind;
}
allow kadmind_t kprop_port_t:tcp_socket name_bind;


I've also tested with the latest selinux-policy-3.7.19-273.el6, that's fine too.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2015-1375.html