Bug 500395 - selinux-policy: setkey executed from initrc_t from if{up,down}-ipsec fails to set policies
selinux-policy: setkey executed from initrc_t from if{up,down}-ipsec fails to...
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: selinux-policy (Show other bugs)
5.3
All Linux
medium Severity medium
: rc
: ---
Assigned To: Daniel Walsh
BaseOS QE
:
Depends On:
Blocks: 503143 515687
  Show dependency treegraph
 
Reported: 2009-05-12 10:57 EDT by Tomas Hoger
Modified: 2009-09-02 03:58 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 503143 515687 (view as bug list)
Environment:
Last Closed: 2009-09-02 03:58:45 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Tomas Hoger 2009-05-12 10:57:30 EDT
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.
Comment 1 Daniel Walsh 2009-05-12 11:20:02 EDT
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
Comment 2 Tomas Hoger 2009-05-12 12:35:56 EDT
/etc/sysconfig/network-scripts/ifup-ipsec
Comment 3 Daniel Walsh 2009-05-12 14:05:15 EDT
What happens if you

chcon -t initrc_exec_t /etc/sysconfig/network-scripts/ifup-ipsec
Comment 4 Tomas Hoger 2009-05-13 06:05:28 EDT
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.
Comment 5 Tomas Mraz 2009-05-13 06:27:35 EDT
That sounds like a bug in selinux-policy then.
Comment 6 Daniel Walsh 2009-05-13 10:17:05 EDT
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.
Comment 7 Tomas Hoger 2009-05-15 12:21:03 EDT
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.
Comment 8 Tomas Hoger 2009-05-25 11:32:03 EDT
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?
Comment 9 Daniel Walsh 2009-05-26 09:20:17 EDT
It should be allowed, adding

init_read_script_tmp_files(setkey_t)

WIll fix.

Fixed in selinux-policy-2.4.6-237.el5
Comment 10 Tomas Hoger 2009-05-26 09:27:02 EDT
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?
Comment 11 Daniel Walsh 2009-05-26 11:51:47 EDT
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.
Comment 12 Bill Nottingham 2009-05-26 12:26:32 EDT
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.
Comment 13 Tomas Hoger 2009-05-29 05:11:48 EDT
(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.
Comment 14 Daniel Walsh 2009-05-29 07:58:17 EDT
Yes, which of them are failing when run as initrc_t?
Comment 15 Tomas Hoger 2009-05-29 08:34:32 EDT
Only *-ipsec that I know of at the moment.  I've updated my comment in bug #503143, sorry for confusion.
Comment 24 errata-xmlrpc 2009-09-02 03:58:45 EDT
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

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