This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 503143 - selinux-policy: racoon may run as unconfined_t
selinux-policy: racoon may run as unconfined_t
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: selinux-policy (Show other bugs)
11
All Linux
medium Severity medium
: ---
: ---
Assigned To: Daniel Walsh
Fedora Extras Quality Assurance
:
Depends On: 500395
Blocks:
  Show dependency treegraph
 
Reported: 2009-05-29 04:56 EDT by Tomas Hoger
Modified: 2009-08-21 17:55 EDT (History)
5 users (show)

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


Attachments (Terms of Use)

  None (edit)
Description Tomas Hoger 2009-05-29 04:56:42 EDT
+++ This bug was initially created as a clone of Bug #500395 +++

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.

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).
Comment 1 Tomas Hoger 2009-05-29 05:07:54 EDT
See bug #500395 for further discussion about this.  Current options for fixing seem to be:

1) Change type of if{up,down}-ipsec or if{up,down} to initrc_exec_t, so the transition to initrc_t happens when ifup/ifdown is run directly from the command line.

Pros: Consistency with situations when if{up,down} is run during boot / shutdown, or when admin calls /etc/init.d/network.  Currently, running /etc/init.d/network will run up/down scripts as initrc_t, while directly calling ifup/ifdown will run them as unconfined_t in most cases.

Cons: Higher risk for scripts that may not be commonly (at all?) from during boot shutdown, and may not work when run as initrc_t (they should though, imo).

2) Change if{up,down}-ipsec to call racoon's init script instead of running daemon directly.

Pros: Smaller change, less risk.

Cons: Does not deal with inconsistency mentioned above (and which is not specific to this bug).  Depends on bug #500571.
Comment 2 Tomas Hoger 2009-05-29 08:33:33 EDT
To correct / extend my 1) Cons:.

No up/down script besides -ipsec one is currently known to have problems running as initrc_t.

Additional risk was pointed out by Daniel in bug #500395#c11 - it's currently unclear if any domain executing ifup / ifdown may be disallowed to execute initrc_exec_t files.
Comment 3 Daniel Walsh 2009-06-01 13:05:19 EDT
Well mostly ifup and ifdown are run under the domain that starts them,  So if they are run by a user they will run in the users domain, (unconfined_t)  If they are run at startup they will be run in initrc_t, if they are run by NetworkManager then NetworkManager_t
Comment 4 Bug Zapper 2009-06-09 12:45:27 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 5 Daniel Walsh 2009-08-21 17:55:10 EDT
I am not sure we came to closure on this, but I will close as insufficient data, reopen if you have more requests.

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