Description of problem: Red Hat Enterprise Linux 5 Deployment Guide describes how to do a basic IPSec config using ipsec-tools and networking init scripts: http://www.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5/html/Deployment_Guide/s2-ipsec-host2host-cfg.html When ifup is used manually to activate first ipsec interface (which triggers racoon daemon start), racoon is run as unconfined_t, instead of expected raccon_t. This does not happen when ipsec network interface is ONBOOT=yes and hence racoon is started during the system boot. Version-Release number of selected component (if applicable): # rpm -q ipsec-tools selinux-policy ipsec-tools-0.6.5-13.el5 selinux-policy-2.4.6-203.el5 Steps to Reproduce: 1. create minimal ipsec setup as described by Deployment Guide 2. ifup ipsecX 3. check racoon's type Actual results: unconfined_t Expected results: racoon_t Additional info: This is initially filed against ipsec-tools, but it'll probably get addressed via a fix in either initscripts (some runcon hack; addition of init script to get called by if{up,down}-ipsec), or selinux-policy (unconfined_t -> racoon_t type_transition besides initrc_t -> racoon_t one). This should affect Fedora too, but ipsec-tools packages in Fedora provides init script for racoon, so when enabled, racoon should start during the system boot using the right context.
What script is is running to start racoon? That script should be labeled initrc_exec_t or the script starting racoon should be using the initrc_exec_t script under /etc/init.d
/etc/sysconfig/network-scripts/ifup-ipsec
What happens if you chcon -t initrc_exec_t /etc/sysconfig/network-scripts/ifup-ipsec
It results in: type=AVC msg=audit(1242205455.211:203): avc: denied { read } for pid=6807 comm="setkey" path=2F746D702F73682D7468642D31323432323334363432202864656C6574656429 dev=dm-0 ino=1540486 scontext=root:system_r:setkey_t:s0 tcontext=root:object_r:initrc_tmp_t:s0 tclass=file and fails to set policies properly (!!). Going one step back to the original type for ifup-ipsec and re-testing with ONBOOT=yes, racoon does get run as racoon_t, but setkey fails and hence no policies are set. Am I missing something obvious here or do we have a problem here? Adding also Bill to CC as initscripts maintainer / guru.
That sounds like a bug in selinux-policy then.
The problem is the script is now transitioning properly, but it is creating /tmp/sh-thd-1242234642 files incorrectly The F11 script creates all of the tmp files in /etc/racoon which ends up with a label that setkeys can read.
From what I can see, that temporary file is not created directly by ifup-ipsec, but rather indirectly by bash, due to the use of here documents to pipe inputs into setkey. This problem does affect F10 and diffing ifup-ipsec to current git version, I don't see a reason why it should not affect F11 too.
I checked bash sources to see if it may be possible to change temporary file location via e.g. TMPDIR environment variable, which could be a trivial fix for if{up,down}-ipsec. sh_mktmpfd() in lib/sh/tmpfile.c calls get_tmpdir(), which does have support for $TMPDIR, though it is not allowed in the call from here_document_to_fd() (redir.c, no MT_USETMPDIR in flags). Hence no-go. If setkey_t should not be allowed to read initrc_tmp_t, initscripts need to be modified. One possibility is to replace all 'setkey -c' calls with: tmpfile=`mktemp /etc/racoon/setkey.XXXXXX` < fill tmpfile > setkey -f $tmpfile rm -rf $tmpfile Although, this seems to work too: -/sbin/setkey -c >/dev/null 2>&1 << EOF +cat << EOF | /sbin/setkey -c >/dev/null 2>&1 so the cat is reading here document temporary file and setkey is really seeing input on stdin. Regarding the file type changes, I don't quite like the idea of only changing the type of if{up,down}-ipsec to initrc_exec_t. Other if{up,down}-* scripts can be run as initrc_t too, as (I believe) any of them can be run from /etc/init.d/network. So all of them may need to have their type changed to ensure same domain is used whether executed from network init script or using ifup/ifdown from the command line. Actually, it may be better to just change type of (/sbin/)if{up,down} directly. As for the racoon's domain, I'd probably prefer to see racoon init script called from if{up,down}-ipsec, though that depends on the init script being fixed first (bug #500571, reload action should not do restart, status should return correct exit codes), and, in RHEL5's case, to be included in ipsec-tools packages at all (bug #500570). This may only be doable in future RHEL/Fedora versions. Bill, Daniel, any comments?
It should be allowed, adding init_read_script_tmp_files(setkey_t) WIll fix. Fixed in selinux-policy-2.4.6-237.el5
Wait, that's only one of the issues (the worse one though). This was first opened for racoon running as unconfined_t. Do we have an agreed-upon fix for that?
I guess not yet. After rereading your message I guess I would say we can experiment with Rawhide, but changing more then just the ifup-ipsec script to initrc_exec_t is dangerous. For example, I am not sure what other domains execute ifup and ifdown, and would be denied if they were labeled initrc_exec_t.
1) Having it write the here documents to /etc isn't preferred; after all, that's not necessarily writable. Ideally it would be fixed to be a different sort of pipe, I suppose. 2) Ideally, we'd have ipsec solutions that aren't all fragile... without replacing all of ipsec-tools and openswan, that's not real likely.
(In reply to comment #11) > I guess I would say we can experiment with Rawhide, but changing more then just > the ifup-ipsec script to initrc_exec_t is dangerous. For example, I am not > sure what other domains execute ifup and ifdown, and would be denied if they > were labeled initrc_exec_t. If all ifup-* / ifdown-* scripts are expected to be run from /etc/init.d/network, any of them failing when run as initrc_t should be a bug, imo. I've re-titled this bug to make it setkey problem specific and created separate bug for racoon issue - bug #503143.
Yes, which of them are failing when run as initrc_t?
Only *-ipsec that I know of at the moment. I've updated my comment in bug #503143, sorry for confusion.
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-2009-1242.html