Description of problem: Init generates a series of config files used by racoon that are created to initialize an IPSEC connect. If the ipsec connection is meant to start on boot, selinux denies the attemp to read the config file and prevents the connection properly starting up. I suspect this doesnt get normally reported because setroubleshoot is started after networking is. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. Create an IPSEC connection in the redhat way (using network-scripts) 2. Run "ifup ipsec_name". This works because root runs unconfined. 3. Run service network restart. This fails because you transition to init_t. Actual results: The ipsec connection fails to start if ran via the init_t domain. Expected results: The ipsec connection should start if ran via the init_t domain. ---- policy_module(myipsec,0.0.1) require { type setkey_t; } init_rw_script_tmp_files(setkey_t) ---- Additional info: This causes raccoon to come up but not correctly setup its associations (as it cant read the file). This has the knock-on affect of responding to internet key exchanges at phase 1 then failing. This, in turn causes the other end of the ipsec connection to block awaiting the phase 2 negotiation. If you leave it like this long enough any services that rely on the secure connection will block stopping their operation. This has system wide affects if, say resolv.conf lists a nameserver which relies on the ipsec connection unintentionally denying services on the remote side. I dont run in tunnel mode but I presume the condition would be worse and/or cause other odd network affects to those on the tunnels endpoints local network.
I think this is enough. init_read_script_tmp_files(setkey_t) This has been reported, and a fix is ready but currently we are frozen in RHEL5.4. Fix will be in RHEL5.5.
Fixed in selinux-policy-2.4.6-257.el5 Preview release available at http://people.redhat.com/dwalsh/SELinux/RHEL5
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2010-0182.html