Description of problem: On system startup, presumably when strongswan-starter service started. SELinux is preventing starter from 'connectto' accesses on the unix_stream_socket /run/strongswan/charon.ctl. ***** Plugin catchall (100. confidence) suggests ************************** If you believe that starter should be allowed connectto access on the charon.ctl unix_stream_socket by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # ausearch -c 'starter' --raw | audit2allow -M my-starter # semodule -X 300 -i my-starter.pp Additional Information: Source Context system_u:system_r:ipsec_t:s0 Target Context system_u:system_r:ipsec_mgmt_t:s0 Target Objects /run/strongswan/charon.ctl [ unix_stream_socket ] Source starter Source Path starter Port <Unknown> Host (removed) Source RPM Packages Target RPM Packages SELinux Policy RPM selinux-policy-3.14.4-49.fc31.noarch Local Policy RPM selinux-policy-targeted-3.14.4-49.fc31.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name (removed) Platform Linux (removed) 5.5.10-200.fc31.x86_64 #1 SMP Wed Mar 18 14:21:38 UTC 2020 x86_64 x86_64 Alert Count 4 First Seen 2020-03-22 11:52:10 EDT Last Seen 2020-03-22 11:57:15 EDT Local ID e44f8fb7-b6cf-403b-a6dc-30b8475eea70 Raw Audit Messages type=AVC msg=audit(1584892635.285:306): avc: denied { connectto } for pid=2518 comm="starter" path="/run/strongswan/charon.ctl" scontext=system_u:system_r:ipsec_t:s0 tcontext=system_u:system_r:ipsec_mgmt_t:s0 tclass=unix_stream_socket permissive=0 Hash: starter,ipsec_t,ipsec_mgmt_t,unix_stream_socket,connectto Version-Release number of selected component: selinux-policy-3.14.4-49.fc31.noarch Additional info: component: selinux-policy reporter: libreport-2.12.0 hashmarkername: setroubleshoot kernel: 5.5.10-200.fc31.x86_64 type: libreport
# ls -l /run/strongswan total 0 srwxrwx---. 1 root root 0 Mar 22 11:57 charon.ctl srwxrwx---. 1 root root 0 Mar 22 11:57 charon.dck srwxrwx---. 1 root root 0 Mar 22 11:57 charon.vici # restorecon -rv /run/strongswan/ Relabeled /run/strongswan/charon.vici from system_u:object_r:ipsec_var_run_t:s0 to system_u:object_r:var_run_t:s0 Relabeled /run/strongswan/charon.ctl from system_u:object_r:ipsec_var_run_t:s0 to system_u:object_r:var_run_t:s0 Relabeled /run/strongswan/charon.dck from system_u:object_r:ipsec_var_run_t:s0 to system_u:object_r:var_run_t:s0 # systemctl restart strongswan-starter.service # systemctl status strongswan-starter.service [...] Mar 23 00:38:36 edison strongswan[227293]: connecting to 'unix:///run/strongswan/charon.ctl' failed: Permission denied Mar 23 00:38:36 edison strongswan[227293]: failed to connect to stroke socket 'unix:///run/strongswan/charon.ctl' # rm /run/strongswan/* rm: remove socket '/run/strongswan/charon.ctl'? y rm: remove socket '/run/strongswan/charon.dck'? y rm: remove socket '/run/strongswan/charon.vici'? y # systemctl restart strongswan-starter.service [no errors] # restorecon -nrv /run/strongswan/ Would relabel /run/strongswan/charon.vici from system_u:object_r:ipsec_var_run_t:s0 to system_u:object_r:var_run_t:s0 Would relabel /run/strongswan/charon.ctl from system_u:object_r:ipsec_var_run_t:s0 to system_u:object_r:var_run_t:s0 Would relabel /run/strongswan/charon.dck from system_u:object_r:ipsec_var_run_t:s0 to system_u:object_r:var_run_t:s0
I've submitted a Fedora PR to address the issue: https://github.com/fedora-selinux/selinux-policy/pull/334 as well as add label for /run/strongswan to cover the following change: * Sat Dec 28 2019 Paul Wouters <pwouters> - 5.8.2-2 - Use /run/strongswan as rundir to support strongswans in namespaces
Raman, One thing is not quite clear for me: If you don't relabel the socket files and let them keep the ipsec_var_run_t context which is the correct one, the connectto denial still appears? Does the same denial appear when the daemon is started using swanctl which should be preferred if I understand coorectly? https://bugzilla.redhat.com/show_bug.cgi?id=1773381#c0 and c4 Also note that in Strongswan 5.8 they have changed the service names around to reflect the fact that the swanctl startup method is considered the new normal way of using the daemon.
commit a9a124efb4b03f40c01b66a73deb59f364281f86 (HEAD -> rawhide, origin/rawhide) Author: Zdenek Pytela <zpytela> Date: Mon Mar 23 16:05:26 2020 +0100 Allow ipsec_t connectto ipsec_mgmt_t Allow ipsec_t connectto ipsec_mgmt_t using unix_stream_socket. Label /run/strongswan with ipsec_var_run_t. Resolves: rhbz#1815983
(In reply to Zdenek Pytela from comment #3) > Raman, > > One thing is not quite clear for me: If you don't relabel the socket files > and let them keep the ipsec_var_run_t context which is the correct one, the > connectto denial still appears? I thought that was odd too. I got the AVC denial at startup, so I don't know why those files wouldn't have had the correct labels by default. Perhaps an automatic relabel at boot time? > Does the same denial appear when the daemon is started using swanctl which > should be preferred if I understand coorectly? I couldn't figure out how to do this, and couldn't find any documentation. I just get errors like this: [root@edison ~]# swanctl --list-conns connecting to 'unix:///run/strongswan/charon.vici' failed: Connection refused Error: connecting to 'default' URI failed: Connection refused and if I delete everything in /run/strongswan: [root@edison ~]# swanctl --list-conns connecting to 'unix:///run/strongswan/charon.vici' failed: No such file or directory Error: connecting to 'default' URI failed: No such file or directory Not sure where to go from here... > https://bugzilla.redhat.com/show_bug.cgi?id=1773381#c0 and c4 > > Also note that in Strongswan 5.8 they have changed the service names around > to reflect the fact that the swanctl startup method is considered the new > normal way of using the daemon. I am on F31 -- the latest version available in the stable repos still seems to be 5.7.1. There is no strongswan-swanctl service as referenced in the issue above.
The latest F31 version is strongswan-5.8.2-3.fc31, so please update. It contains the following systemd service unit files: /usr/lib/systemd/system/strongswan-starter.service /usr/lib/systemd/system/strongswan.service The selinux-policy package update allowing the connectto permission will be available later.
(In reply to Zdenek Pytela from comment #6) > The latest F31 version is strongswan-5.8.2-3.fc31, so please update. Sorry, I misspoke earlier. I checked again and I am actually already on 5.8.2-3.fc31. > It contains the following systemd service unit files: > > /usr/lib/systemd/system/strongswan-starter.service > /usr/lib/systemd/system/strongswan.service It has no strongswan-swanctl.service as was mentioned in https://bugzilla.redhat.com/show_bug.cgi?id=1773381#c4? So what is the recommended way to start strongswan, if strongswan-swanctl is not available, and strongswan-starter is not recommended? > The selinux-policy package update allowing the connectto permission will be > available later. Great.
FEDORA-2020-6d33cc238c has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2020-6d33cc238c
FEDORA-2020-6d33cc238c has been pushed to the Fedora 31 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-6d33cc238c` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-6d33cc238c See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2020-6d33cc238c has been pushed to the Fedora 31 stable repository. If problem still persists, please make note of it in this bug report.