Bug 1225105

Summary: Incremental propagation is not working since kpropd got its own selinux-domain
Product: Red Hat Enterprise Linux 6 Reporter: Patrik Kis <pkis>
Component: krb5Assignee: Kerberos Developers <kerberos-dev-list>
Status: CLOSED NOTABUG QA Contact: BaseOS QE Security Team <qe-baseos-security>
Severity: high Docs Contact:
Priority: high    
Version: 6.7CC: dpal, jplans, kerberos-dev-list, mgrepl, nalin, rmainz
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-06-04 07:07:52 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1220691    

Description Patrik Kis 2015-05-26 15:08:53 UTC
Description of problem:
This bz was opened to discuss the following AVC denial caused by kpropd after it got its own selinux doamin.

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


The main question here is what kpropd is trying to do here.


Version-Release number of selected component (if applicable):
krb5-libs-1.10.3-42.el6.x86_64
selinux-policy-3.7.19-269.el6.noarch

How reproducible:
always

Steps to Reproduce:
1. Set up incremental pripagation
(should you need more detail, feel free to ask)

Actual results:
AVC denial are logged and the propagation fails

Expected results:
no AVC denials and the propagation is working

Comment 3 Patrik Kis 2015-05-27 09:03:07 UTC
To me this looks like a normal operation: kpropd initiate a connection to kadmind via TCP:272 that should be allowed.

Comment 4 Miroslav Grepl 2015-05-27 15:44:43 UTC
Is this anything new?

Comment 5 Patrik Kis 2015-05-28 12:43:14 UTC
(In reply to Miroslav Grepl from comment #4)
> Is this anything new?

As far as I know not, it's here for some time already.
@Roland, can you confirm, plase?

We just had no test for it + it run in unconfined domain, so it was not noticed.