Bug 858872 - KDC incremental propagation fails when iprop_full_resync is attempted by kadmind
KDC incremental propagation fails when iprop_full_resync is attempted by kadmind
Status: CLOSED NEXTRELEASE
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: selinux-policy (Show other bugs)
6.3
x86_64 Unspecified
unspecified Severity medium
: rc
: ---
Assigned To: Miroslav Grepl
BaseOS QE Security Team
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-09-19 17:19 EDT by Karl Grose
Modified: 2013-10-02 17:06 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-10-02 17:06:36 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
audit.log events related to kadmind (18.69 KB, text/plain)
2012-09-21 12:41 EDT, Karl Grose
no flags Details

  None (edit)
Description Karl Grose 2012-09-19 17:19:18 EDT
Description of problem: When incremental propagation is configured for Kerberos and kadmind attempts a full re-sync, SELinux policy prevents this. Making SELinux permissive or installing a custom policy module allows the full re-sync to succeed.


Version-Release number of selected component (if applicable):krb5-server.x86_64                                             1.9-33.el6_3.3


How reproducible: Enable incremental propagation to a slave KDC; then remove the slave's KDC database to force a full resync. kadmind on the master KDC will attempt to launch a kprop to the slave which will be denied by SELinux.


Steps to Reproduce:
1. Edit kdc.conf to enable iprop; I used 755/tcp for the iprop port; define the necessary iprop principals and update the host keytabs as documented in the Kerberos installation guide.
2. On the slave KDC stop the krb5kdc process and remove the principal* files (the KDC database files) from /var/kerberos/krb5kdc to force a full resync
3. On the slave KDC, restart kpropd in standalone debug mode (-d -S) which then contacts the master KDC and requests the full resync
4. Note that both the kadmind and kpropd logs record errors which correspond to SELinux denials for various kadmind operations during the full re-sync attempt
  
Actual results: The incremental propagation fails to do a full re-sync of the KDC database on the slave KDC and subsequent incremental changes cannot be propagated.


Expected results: If the proper SELinux policy is in place (see example below), the full re-sync succeeds and then any subsequent incremental changes are sent as well.


Additional info: Example SELinux policy module (generated from entries in the audit log following a failure) that permits the full re-sync to succeed:

cat kiprop.te 

module kiprop 1.0;

require {
        type selinux_config_t;
        type bin_t;
        type kadmind_t;
        type hi_reserved_port_t;
        type kprop_port_t;
        type krb5_keytab_t;
        type krb5kdc_conf_t;
        type shell_exec_t;
        type dhcpd_port_t;
        class tcp_socket { name_bind name_connect };
        class lnk_file read;
        class fifo_file ioctl;
        class file { execute read lock create execute_no_trans write getattr unlink open };
}

#============= kadmind_t ==============
allow kadmind_t bin_t:file { read execute open execute_no_trans };
allow kadmind_t bin_t:lnk_file read;
#!!!! This avc can be allowed using the boolean 'allow_ypbind'

allow kadmind_t dhcpd_port_t:tcp_socket name_bind;
#!!!! This avc can be allowed using the boolean 'allow_ypbind'

allow kadmind_t hi_reserved_port_t:tcp_socket name_bind;
#!!!! This avc can be allowed using the boolean 'allow_ypbind'

allow kadmind_t kprop_port_t:tcp_socket name_connect;
allow kadmind_t krb5_keytab_t:file { read lock open };
allow kadmind_t krb5kdc_conf_t:file { write create unlink };
allow kadmind_t self:fifo_file ioctl;
allow kadmind_t selinux_config_t:file { read getattr open };
allow kadmind_t shell_exec_t:file { read execute open getattr execute_no_trans };
Comment 2 Nalin Dahyabhai 2012-09-21 11:53:05 EDT
Do you have the audit logs messages which were produced when you did this?

Some of the additions made in your module are probably specific to your use of port 755, while I expect that the policy changes would want to be parameterized around a named port type (akin to the kerberos_admin_port_t and kprop_port_t which already exist), to which 755/tcp could be added.
Comment 3 Karl Grose 2012-09-21 12:41:05 EDT
Created attachment 615516 [details]
audit.log events related to kadmind

audit log events used to create policy with audit2allow
Comment 4 Nalin Dahyabhai 2012-09-21 16:08:02 EDT
Thanks for those - kprop, which historically was run from a shell or a cron job, and which therefore could do things like establish network connections and use keytabs without issue, is being invoked by kadmind here, and the SELinux domain in which kadmind runs has not previously been allowed to do most of these things.
Comment 5 Daniel Walsh 2012-09-25 17:10:51 EDT
I don't have a problem allowing these.

These seem weird

allow kadmind_t dhcpd_port_t:tcp_socket name_bind;
allow kadmind_t hi_reserved_port_t:tcp_socket name_bind;

Is kadmind picking out random ports to bind to?
Comment 6 RHEL Product and Program Management 2012-12-14 03:17:31 EST
This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.
Comment 7 Miroslav Grepl 2012-12-14 05:33:50 EST
Karl,
could you test how it looks with the latest policy

http://people.redhat.com/dwalsh/SELinux/RHEL6/noarch/
Comment 8 Karl Grose 2012-12-17 16:39:37 EST
(In reply to comment #7)

> could you test how it looks with the latest policy
> 
> http://people.redhat.com/dwalsh/SELinux/RHEL6/noarch/

This new policy does indeed look to resolve my issue. The full resync propagation was triggered and was allowed to complete without error.

--Karl

Note You need to log in before you can comment on or make changes to this bug.