Собственно проблема обозначена в сабже. При запуске systemctl start strongswan-swanctl.service
не стартует и пишет в логи
May 05 02:27:30 msk.vbezhenar.com systemd[1]: Starting strongSwan IPsec IKEv1/IKEv2 daemon using swanctl...
May 05 02:27:30 msk.vbezhenar.com charon-systemd[1681]: PKCS11 module '<name>' lacks library path
May 05 02:27:30 msk.vbezhenar.com charon-systemd[1681]: openssl FIPS mode(2) - enabled
May 05 02:27:30 msk.vbezhenar.com charon-systemd[1681]: loading ca certificates from '/etc/strongswan/ipsec.d/cacerts'
May 05 02:27:30 msk.vbezhenar.com charon-systemd[1681]: loading aa certificates from '/etc/strongswan/ipsec.d/aacerts'
May 05 02:27:30 msk.vbezhenar.com charon-systemd[1681]: loading ocsp signer certificates from '/etc/strongswan/ipsec.d/ocspcerts'
May 05 02:27:30 msk.vbezhenar.com charon-systemd[1681]: loading attribute certificates from '/etc/strongswan/ipsec.d/acerts'
May 05 02:27:30 msk.vbezhenar.com charon-systemd[1681]: loading crls from '/etc/strongswan/ipsec.d/crls'
May 05 02:27:30 msk.vbezhenar.com charon-systemd[1681]: loading secrets from '/etc/strongswan/ipsec.secrets'
May 05 02:27:30 msk.vbezhenar.com charon-systemd[1681]: opening triplet file /etc/strongswan/ipsec.d/triplets.dat failed: No such file or directory
May 05 02:27:30 msk.vbezhenar.com charon-systemd[1681]: loaded 0 RADIUS server configurations
May 05 02:27:30 msk.vbezhenar.com charon-systemd[1681]: HA config misses local/remote address
May 05 02:27:30 msk.vbezhenar.com charon-systemd[1681]: no script for ext-auth script defined, disabled
May 05 02:27:30 msk.vbezhenar.com charon-systemd[1681]: loaded plugins: charon-systemd pkcs11 tpm aes des rc2 sha2 sha1 md4 md5 mgf1 random nonce x509 revocation constraints acert pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey pem openssl gcrypt fips-prf gmp curve25519 chapoly xcbc cmac hmac ctr ccm gcm curl attr kernel-netlink resolve socket-default farp stroke vici updown eap-identity eap-sim eap-aka eap-aka-3gpp eap-aka-3gpp2 eap-md5 eap-gtc eap-mschapv2 eap-dynamic eap-radius eap-tls eap-ttls eap-peap xauth-generic xauth-eap xauth-pam xauth-noauth dhcp led duplicheck unity counters
May 05 02:27:30 msk.vbezhenar.com charon-systemd[1681]: spawning 16 worker threads
May 05 02:27:30 msk.vbezhenar.com swanctl[1698]: no files found matching '/etc/strongswan/strongswan.conf'
May 05 02:27:30 msk.vbezhenar.com swanctl[1698]: abort initialization due to invalid configuration
May 05 02:27:30 msk.vbezhenar.com systemd[1]: strongswan-swanctl.service: Control process exited, code=exited status=64
May 05 02:27:30 msk.vbezhenar.com charon-systemd[1681]: SIGTERM received, shutting down
May 05 02:27:30 msk.vbezhenar.com systemd[1]: strongswan-swanctl.service: Failed with result 'exit-code'.
May 05 02:27:30 msk.vbezhenar.com systemd[1]: Failed to start strongSwan IPsec IKEv1/IKEv2 daemon using swanctl.
Файл /etc/strongswan/strongswan.conf
конечно же на месте и имеет все нужные права (я его вообще не трогал).
[root@msk selinux]# ls -lZ /etc/strongswan/strongswan.conf
-rw-r--r--. 1 root root system_u:object_r:ipsec_conf_file_t:s0 281 Oct 11 2019 /etc/strongswan/strongswan.conf
Есть сделать setenforce permissive
, всё работает. Я запустил его один раз, стопнул, потом через audit2why -b
увидел проблемы (к сожалению вывод потерял). Сгенерировал локальную policy с помощью audit2allow -M local -b
:
module local 1.0;
require {
type ipsec_conf_file_t;
type var_run_t;
type ipsec_mgmt_t;
class dir read;
class lnk_file read;
class file map;
class sock_file write;
}
#============= ipsec_mgmt_t ==============
allow ipsec_mgmt_t ipsec_conf_file_t:dir read;
#!!!! This avc can be allowed using the boolean 'domain_can_mmap_files'
allow ipsec_mgmt_t ipsec_conf_file_t:file map;
allow ipsec_mgmt_t ipsec_conf_file_t:lnk_file read;
allow ipsec_mgmt_t var_run_t:sock_file write;
и загрузил её с помощью semodule -i local.pp
.
Перезагрузился, теперь опять пытаюсь запустить в enforcing режиме и ничего! В permissive-режиме запускается. Но audit2why
теперь вообще ничего не выводит, т.е. просто не запускается с вышеуказанной ошибкой и всё тут. Дальше мои скиллы закончились, помогите одолеть эту проблему без отключения selinux.
strongswan из epel, запускается современным способом через swanctl.
Сейчас попробовал сделать audit2why -a
, пишет следующее (это, как я понимаю, старые ошибки, оно и пишет мол сейчас их не должно быть):
type=AVC msg=audit(1588551574.568:111950): avc: denied { read } for pid=7095 comm="swanctl" name="charon" dev="vda3" ino=1074454 scontext=system_u:system_r:ipsec_mgmt_t:s0 tcontext=system_u:object_r:ipsec_conf_file_t:s0 tclass=dir permissive=1
Was caused by:
Unknown - would be allowed by active policy
Possible mismatch between this policy and the one under which the audit message was generated.
Possible mismatch between current in-memory boolean settings vs. permanent ones.
type=AVC msg=audit(1588551574.616:111951): avc: denied { write } for pid=7095 comm="swanctl" name="charon.vici" dev="tmpfs" ino=675887 scontext=system_u:system_r:ipsec_mgmt_t:s0 tcontext=system_u:object_r:var_run_t:s0 tclass=sock_file permissive=1
Was caused by:
Unknown - would be allowed by active policy
Possible mismatch between this policy and the one under which the audit message was generated.
Possible mismatch between current in-memory boolean settings vs. permanent ones.
type=AVC msg=audit(1588551574.617:111952): avc: denied { read } for pid=7095 comm="swanctl" name="vbezhenar.com-cert.pem" dev="vda3" ino=67636295 scontext=system_u:system_r:ipsec_mgmt_t:s0 tcontext=unconfined_u:object_r:ipsec_conf_file_t:s0 tclass=lnk_file permissive=1
Was caused by:
Unknown - would be allowed by active policy
Possible mismatch between this policy and the one under which the audit message was generated.
Possible mismatch between current in-memory boolean settings vs. permanent ones.
type=AVC msg=audit(1588551574.619:111953): avc: denied { map } for pid=7095 comm="swanctl" path="/etc/strongswan/swanctl/private/vbezhenar.com-privkey.pem" dev="vda3" ino=101266879 scontext=system_u:system_r:ipsec_mgmt_t:s0 tcontext=unconfined_u:object_r:ipsec_conf_file_t:s0 tclass=file permissive=1
Was caused by:
Unknown - would be allowed by active policy
Possible mismatch between this policy and the one under which the audit message was generated.
Possible mismatch between current in-memory boolean settings vs. permanent ones.
Кстати, тогда ошибки при запуске в enforcing режиме тоже не появлялись никакие, появились только после запуска в permissive режиме.