Bug 1014818 - swan (ipsec) fails to start as it is prohibited to write to cert DB due to selinux
swan (ipsec) fails to start as it is prohibited to write to cert DB due to se...
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: libreswan (Show other bugs)
19
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Paul Wouters
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-10-02 16:48 EDT by QingLong
Modified: 2014-09-19 06:16 EDT (History)
5 users (show)

See Also:
Fixed In Version: libreswan-3.10-3.fc19
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-09-19 06:12:25 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)

  None (edit)
Description QingLong 2013-10-02 16:48:48 EDT
Description of problem:
Pluto (ipsec connection manager) tries to write (what?) to /etc/ipsec.d/cert9.db
on start, and been denied by selinux fails.

Version-Release number of selected component (if applicable):
libreswan-3.5-2.fc19

How reproducible:
Always

Steps to Reproduce:
1.Set selinux to Enforcing mode.
2.Start ipsec.service
3.Watch the failure.

Actual results:
 The ipsec.service fails.
 In the /var/log/messages:
|
| systemd[1]: Started Internet Key Exchange (IKE) Protocol Daemon for IPsec.
| ipsec[12666]: whack: Pluto is not running (no "/var/run/pluto/pluto.ctl")
| systemd[1]: ipsec.service: control process exited, code= exited status=1
| systemd[1]: Unit ipsec.service entered failed state.
| systemd[1]: ipsec.service holdoff time over, scheduling restart.
| systemd[1]: Stopping Internet Key Exchange (IKE) Protocol Daemon for IPsec...
| systemd[1]: Starting Internet Key Exchange (IKE) Protocol Daemon for IPsec...
| systemd[1]: ipsec.service start request repeated too quickly, refusing to start.
| systemd[1]: Failed to start Internet Key Exchange (IKE) Protocol Daemon for IPsec.
| systemd[1]: Unit ipsec.service entered failed state.
|
 /var/log/secure:
|
| pluto[12664]: nss directory plutomain: /etc/ipsec.d
| pluto[12664]: NSS initialization failed (err -8187)
|
 /var/log/audit/audit.log:
|
| type=AVC msg=audit(1380744002.589:205): avc: denied { write } for pid=12664 comm="pluto" name="cert9.db" dev="sda2" ino=755 scontext=system_u:system_r:ipsec_t:s0 tcontext=unconfined_u:object_r:etc_t:s0 tclass=file
|

Expected results:
Pluto should run.

Additional info:
Switching selinux to Permissive elimiates the obstacle,
and pluto successfully starts (as well as the whole ipsec service).

Pluto should NOT mangle authentication databases! Never.
Moreover, all the stuff under /etc/ MUST be considered read-only besides administration activity, especially by network related processes (both daemons and clients).
Comment 1 Paul Wouters 2013-10-02 16:55:10 EDT
While this can be fixed for now by pluto opening the nss in readonly, there is the issue of CRL updates that will have to go into the ipsec NSS database, that currently lives in /etc/ipsec.d/
Comment 2 Tuomo Soini 2013-10-03 11:20:49 EDT
The labeling of /etc/ipsec.d dir is broken on fedora 19.
Comment 3 QingLong 2013-10-03 13:14:21 EDT
The labeling of ipsec.d maybe broken, but the main point (problem) is the idea of allowing pluto to perform administration in /etc/, rahther than selinux mislabeling.
Actually by the moment there are no real (signed by peer or some authoritative third party) certificates in this libreswan installation, thus there is no need to play ca/crl games at all. Nevertheless libreswan tries to write some (obviously senseless) thing to the database. What for?
Even in the case of certificates games, why not use /var/? Say the localhost keys and certificates live under /etc/ and are only managed by administrator (never by any automatic agents (daemons, cron jobs, etc)), while all the other stuff (certificates, revocations, etc) goes to /var/. Is NSS able to run in such splitted configuration (1 key.db and several cert.db's residing in different directories)?
Comment 4 Fedora Update System 2014-07-11 11:53:23 EDT
libreswan-3.9-1.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/libreswan-3.9-1.fc20
Comment 5 Fedora Update System 2014-07-11 11:54:28 EDT
libreswan-3.9-1.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/libreswan-3.9-1.fc19
Comment 6 Fedora Update System 2014-07-11 22:21:45 EDT
Package libreswan-3.9-1.fc19:
* should fix your issue,
* was pushed to the Fedora 19 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing libreswan-3.9-1.fc19'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2014-8272/libreswan-3.9-1.fc19
then log in and leave karma (feedback).
Comment 7 Fedora Update System 2014-09-09 15:17:44 EDT
libreswan-3.10-3.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/libreswan-3.10-3.fc20
Comment 8 Fedora Update System 2014-09-09 15:30:15 EDT
libreswan-3.10-3.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/libreswan-3.10-3.fc19
Comment 9 Fedora Update System 2014-09-19 06:12:25 EDT
libreswan-3.10-3.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 10 Fedora Update System 2014-09-19 06:16:33 EDT
libreswan-3.10-3.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.

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