DescriptionPhilip Prindeville
2020-10-19 23:32:36 UTC
+++ This bug was initially created as a clone of Bug #1773381 +++
Description of problem:
Occurs when starting strongswan-swanctl.service.
Note that Strongswan has two services for two different ways of configuring/invoking the daemon. This happens for the strongswan-swanctl.service which uses swanctl to load configuration at startup. I'm guessing that is what causes this denial.
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.
SELinux is preventing swanctl from 'search' accesses on the directory strongswan.
***** Plugin catchall (100. confidence) suggests **************************
If you believe that swanctl should be allowed search access on the strongswan directory 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 'swanctl' --raw | audit2allow -M my-swanctl
# semodule -X 300 -i my-swanctl.pp
Additional Information:
Source Context system_u:system_r:ipsec_mgmt_t:s0
Target Context system_u:object_r:ipsec_conf_file_t:s0
Target Objects strongswan [ dir ]
Source swanctl
Source Path swanctl
Port <Unknown>
Host (removed)
Source RPM Packages
Target RPM Packages
Policy RPM selinux-policy-3.14.3-46.fc30.noarch
Selinux Enabled True
Policy Type targeted
Enforcing Mode Enforcing
Host Name (removed)
Platform Linux (removed) 5.3.7-200.fc30.x86_64 #1 SMP Fri
Oct 18 20:13:59 UTC 2019 x86_64 x86_64
Alert Count 1
First Seen 2019-11-18 09:32:11 AEST
Last Seen 2019-11-18 09:32:11 AEST
Local ID bd1ddc85-3676-4790-84dd-7c40c76c7b08
Raw Audit Messages
type=AVC msg=audit(1574033531.581:40757): avc: denied { search } for pid=11826 comm="swanctl" name="strongswan" dev="dm-0" ino=3164535 scontext=system_u:system_r:ipsec_mgmt_t:s0 tcontext=system_u:object_r:ipsec_conf_file_t:s0 tclass=dir permissive=0
Hash: swanctl,ipsec_mgmt_t,ipsec_conf_file_t,dir,search
Version-Release number of selected component:
selinux-policy-3.14.3-46.fc30.noarch
Additional info:
component: selinux-policy
reporter: libreport-2.10.1
hashmarkername: setroubleshoot
kernel: 5.3.7-200.fc30.x86_64
type: libreport
--- Additional comment from Zdenek Pytela on 2019-11-18 07:47:34 UTC ---
Hi Dan,
Thank you for reporting the issue. Could you please gather more data to make the fix complete? Make the ipsec_mgmt_t domain permissive, reproduce, gather audit logs, put the settings back:
# semanage permissive -a ipsec_mgmt_t
<start the service>
# ausearch -i -m avc,user_avc,selinux_err,user_selinux_err -ts recent > /tmp/audit.out
# semanage permissive -d ipsec_mgmt_t
and attach the audit.out to this bugzilla.
Note semanage is a part of policycoreutils-python-utils. Alternatively, you can make the whole system permissive with setenforce 0.
--- Additional comment from Zdenek Pytela on 2019-11-18 15:43:13 UTC ---
I've created a PR to allow the permission:
https://github.com/fedora-selinux/selinux-policy/pull/294
However, some additional permissions are needed.
Strongswan folks, I would like to clarify 2 issues:
1. We have the following file context defined in SELinux policy:
/var/run/charon\.ctl -s gen_context(system_u:object_r:ipsec_var_run_t,s0)
/var/run/charon\.dck -s gen_context(system_u:object_r:ipsec_var_run_t,s0)
/var/run/charon\.vici -s gen_context(system_u:object_r:ipsec_var_run_t,s0)
/var/run/charon.* -- gen_context(system_u:object_r:ipsec_var_run_t,s0)
That is for 3 named socket files and others can be common files or a directories - is it correct?
2. Which process manages these sock files? I see 2 service units in the strongswan package:
strongswan.service execs /usr/sbin/strongswan
strongswan-swanctl.service execs /usr/sbin/charon-systemd and /usr/sbin/swanctl in ExecStartPost
As the sockets got incorrect context:
# ls -Zld /var/run/charon*
srwxrwx---. 1 root root system_u:object_r:var_run_t:s0 0 18. lis 10.25 /var/run/charon.ctl
srwxrwx---. 1 root root system_u:object_r:var_run_t:s0 0 18. lis 10.25 /var/run/charon.dck
srwxrwx---. 1 root root system_u:object_r:var_run_t:s0 0 18. lis 10.25 /var/run/charon.vici
and access to them was subsequently denied by SELinux, it looks like in the second unit the managing process did not run in ipsec_mgmt_t domain. Note the default file context:
# matchpathcon /usr/sbin/charon-systemd /usr/sbin/swanctl /usr/sbin/strongswan
/usr/sbin/charon-systemd system_u:object_r:bin_t:s0
/usr/sbin/swanctl system_u:object_r:ipsec_mgmt_exec_t:s0
/usr/sbin/strongswan system_u:object_r:ipsec_mgmt_exec_t:s0
Is it required to confine the charon-systemd process? If yes, should it run in the same ipsec_mgmt_t domain?
Feel free to switch the component back to selinux-policy.
--- Additional comment from Zdenek Pytela on 2019-11-25 16:18:20 UTC ---
I added a file context proposal to the existing PR:
https://github.com/fedora-selinux/selinux-policy/pull/294
Still, I would like to know if ipsec_mgmt_exec_t is the proper context for /usr/sbin/charon-systemd.
--- Additional comment from Mikhail Zabaluev on 2019-11-25 17:55:21 UTC ---
(In reply to Zdenek Pytela from comment #2)
> Strongswan folks, I would like to clarify 2 issues:
>
> 1. We have the following file context defined in SELinux policy:
>
> /var/run/charon\.ctl -s gen_context(system_u:object_r:ipsec_var_run_t,s0)
> /var/run/charon\.dck -s gen_context(system_u:object_r:ipsec_var_run_t,s0)
> /var/run/charon\.vici -s gen_context(system_u:object_r:ipsec_var_run_t,s0)
> /var/run/charon.* -- gen_context(system_u:object_r:ipsec_var_run_t,s0)
>
> That is for 3 named socket files and others can be common files or a
> directories - is it correct?
Sorry, I don't understand the question. Are you asking if the context given for /var/run/charon.* in the fourth line may apply to objects other than the three named sockets in the non-wildcard rules above, and whether this is correct? Not being a SELinux high priest, I don't understand how these rules are applied.
I'm not sure if the list of sockets can be exhaustively given, either. At least one of them is used by a plugin:
https://wiki.strongswan.org/projects/strongswan/wiki/Vici> 2. Which process manages these sock files? I see 2 service units in the
> strongswan package:
>
> strongswan.service execs /usr/sbin/strongswan
> strongswan-swanctl.service execs /usr/sbin/charon-systemd and /usr/sbin/swanctl in ExecStartPost
These service units are alternative ways to run strongswan, where strongswan-swanctl.service is the more modern one.
In version 5.8.1 that has been pushed to Rawhide, the units have been renamed so that strongswan-swanctl is now named
strongswan and the legacy unit is renamed to strongswan-starter.service.
See coincidental discussion in bug #1775548.
> As the sockets got incorrect context:
> # ls -Zld /var/run/charon*
> srwxrwx---. 1 root root system_u:object_r:var_run_t:s0 0 18. lis 10.25 /var/run/charon.ctl
> srwxrwx---. 1 root root system_u:object_r:var_run_t:s0 0 18. lis 10.25 /var/run/charon.dck
> srwxrwx---. 1 root root system_u:object_r:var_run_t:s0 0 18. lis 10.25 /var/run/charon.vici
>
> and access to them was subsequently denied by SELinux, it looks like in the
> second unit the managing process did not run in ipsec_mgmt_t domain. Note
> the default file context:
> # matchpathcon /usr/sbin/charon-systemd /usr/sbin/swanctl
> /usr/sbin/strongswan
> /usr/sbin/charon-systemd system_u:object_r:bin_t:s0
> /usr/sbin/swanctl system_u:object_r:ipsec_mgmt_exec_t:s0
> /usr/sbin/strongswan system_u:object_r:ipsec_mgmt_exec_t:s0
>
> Is it required to confine the charon-systemd process? If yes, should it run
> in the same ipsec_mgmt_t domain?
Yes, I concur that /usr/sbin/charon-systemd should be given the ipsec_mgmt_exec_t context.
--- Additional comment from Lukas Vrabec on 2019-11-26 13:51:57 UTC ---
commit 714d1efd828effaf180659eee341db16558763c5 (HEAD -> rawhide, origin/rawhide)
Author: Zdenek Pytela <zpytela>
Date: Mon Nov 18 15:34:43 2019 +0100
Allow strongswan start using swanctl method BZ(1773381)
Label /usr/sbin/charon-systemd as ipsec_mgmt_exec_t.
Allow ipsec_mgmt_t access ipsec_conf_file_t directory.
Allow ipsec_mgmt_t map ipsec_key_file_t file.
Allow ipsec_mgmt_t name_bind to dhcpc_port_t, ipsecnat_port_t, isakmp_port_t.
Allow ipsec_mgmt_t net_raw capability.
Allow ipsec_mgmt_t packet_socket create permissions.
--- Additional comment from Zdenek Pytela on 2019-11-26 15:56:11 UTC ---
Mikhail,
Thank you for you response, I would to address some outstanding questions.
(In reply to Mikhail Zabaluev from comment #4)
> (In reply to Zdenek Pytela from comment #2)
> > Strongswan folks, I would like to clarify 2 issues:
> >
> > 1. We have the following file context defined in SELinux policy:
> >
> > /var/run/charon\.ctl -s gen_context(system_u:object_r:ipsec_var_run_t,s0)
> > /var/run/charon\.dck -s gen_context(system_u:object_r:ipsec_var_run_t,s0)
> > /var/run/charon\.vici -s gen_context(system_u:object_r:ipsec_var_run_t,s0)
> > /var/run/charon.* -- gen_context(system_u:object_r:ipsec_var_run_t,s0)
> >
> > That is for 3 named socket files and others can be common files or a
> > directories - is it correct?
>
> Sorry, I don't understand the question. Are you asking if the context given
> for /var/run/charon.* in the fourth line may apply to objects other than the
> three named sockets in the non-wildcard rules above, and whether this is
> correct? Not being a SELinux high priest, I don't understand how these rules
> are applied.
>
> I'm not sure if the list of sockets can be exhaustively given, either. At
> least one of them is used by a plugin:
> https://wiki.strongswan.org/projects/strongswan/wiki/Vici
We have filecontext rules for socket files with the given path, and for plain files with a wildcard. I was asking if this is described in a sufficient way, or is an exhaustive list. The one used by Vici is already present.
These rules apply when selinux context on the filesystem is to be restored or verified.
Context of files created in /var/run is handled by other means, file transition rules.
> > 2. Which process manages these sock files? I see 2 service units in the
> > strongswan package:
> >
> > strongswan.service execs /usr/sbin/strongswan
> > strongswan-swanctl.service execs /usr/sbin/charon-systemd and /usr/sbin/swanctl in ExecStartPost
>
> These service units are alternative ways to run strongswan, where
> strongswan-swanctl.service is the more modern one.
> In version 5.8.1 that has been pushed to Rawhide, the units have been
> renamed so that strongswan-swanctl is now named
> strongswan and the legacy unit is renamed to strongswan-starter.service.
> See coincidental discussion in bug #1775548.
I can't see the update in rawhide, but the context for the service file is handled by a wildcard so it should be okay.
>
> > As the sockets got incorrect context:
> > # ls -Zld /var/run/charon*
> > srwxrwx---. 1 root root system_u:object_r:var_run_t:s0 0 18. lis 10.25 /var/run/charon.ctl
> > srwxrwx---. 1 root root system_u:object_r:var_run_t:s0 0 18. lis 10.25 /var/run/charon.dck
> > srwxrwx---. 1 root root system_u:object_r:var_run_t:s0 0 18. lis 10.25 /var/run/charon.vici
> >
> > and access to them was subsequently denied by SELinux, it looks like in the
> > second unit the managing process did not run in ipsec_mgmt_t domain. Note
> > the default file context:
> > # matchpathcon /usr/sbin/charon-systemd /usr/sbin/swanctl
> > /usr/sbin/strongswan
> > /usr/sbin/charon-systemd system_u:object_r:bin_t:s0
> > /usr/sbin/swanctl system_u:object_r:ipsec_mgmt_exec_t:s0
> > /usr/sbin/strongswan system_u:object_r:ipsec_mgmt_exec_t:s0
> >
> > Is it required to confine the charon-systemd process? If yes, should it run
> > in the same ipsec_mgmt_t domain?
>
> Yes, I concur that /usr/sbin/charon-systemd should be given the
> ipsec_mgmt_exec_t context.
I extended my PR, no further action is required from your side, just ensuring we are on the same page.
--- Additional comment from Mikhail Zabaluev on 2019-11-26 17:07:02 UTC ---
(In reply to Zdenek Pytela from comment #6)
> Mikhail,
>
> Thank you for you response, I would to address some outstanding questions.
>
> (In reply to Mikhail Zabaluev from comment #4)
> > (In reply to Zdenek Pytela from comment #2)
> > > Strongswan folks, I would like to clarify 2 issues:
> > >
> > > 1. We have the following file context defined in SELinux policy:
> > >
> > > /var/run/charon\.ctl -s gen_context(system_u:object_r:ipsec_var_run_t,s0)
> > > /var/run/charon\.dck -s gen_context(system_u:object_r:ipsec_var_run_t,s0)
> > > /var/run/charon\.vici -s gen_context(system_u:object_r:ipsec_var_run_t,s0)
> > > /var/run/charon.* -- gen_context(system_u:object_r:ipsec_var_run_t,s0)
> > >
> > > That is for 3 named socket files and others can be common files or a
> > > directories - is it correct?
> >
> > Sorry, I don't understand the question. Are you asking if the context given
> > for /var/run/charon.* in the fourth line may apply to objects other than the
> > three named sockets in the non-wildcard rules above, and whether this is
> > correct? Not being a SELinux high priest, I don't understand how these rules
> > are applied.
> >
> > I'm not sure if the list of sockets can be exhaustively given, either. At
> > least one of them is used by a plugin:
> > https://wiki.strongswan.org/projects/strongswan/wiki/Vici
> We have filecontext rules for socket files with the given path, and for
> plain files with a wildcard. I was asking if this is described in a
> sufficient way, or is an exhaustive list. The one used by Vici is already
> present.
>
> These rules apply when selinux context on the filesystem is to be restored
> or verified.
> Context of files created in /var/run is handled by other means, file
> transition rules.
OK. I don't see a need for the wildcard rule for plain files now, but the list of
sockets that can be instantiated by plugins should include at least the sockets
found by searching for "piddir" in this reference:
https://wiki.strongswan.org/projects/strongswan/wiki/StrongswanConf
There may be also charon.fifo, but it's only applicable in OpenWRT:
https://wiki.strongswan.org/projects/strongswan/wiki/OpenWrtUCI> > In version 5.8.1 that has been pushed to Rawhide, the units have been
> > renamed so that strongswan-swanctl is now named
> > strongswan and the legacy unit is renamed to strongswan-starter.service.
> > See coincidental discussion in bug #1775548.
> I can't see the update in rawhide, but the context for the service file is
> handled by a wildcard so it should be okay.
This build should have delivered the update:
https://bodhi.fedoraproject.org/updates/FEDORA-2019-877fa124b9> I extended my PR, no further action is required from your side, just
> ensuring we are on the same page.
Thank you. Looking forward to testing your changes.
--- Additional comment from Mikhail Zabaluev on 2019-11-28 06:55:20 UTC ---
--- Additional comment from Fedora Update System on 2019-12-04 07:50:39 UTC ---
FEDORA-2019-e9d8868185 has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-e9d8868185
--- Additional comment from Fedora Update System on 2019-12-05 02:01:00 UTC ---
selinux-policy-3.14.3-53.fc30 has been pushed to the Fedora 30 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-e9d8868185
--- Additional comment from Fedora Update System on 2019-12-06 19:20:57 UTC ---
FEDORA-2019-e9d8868185 has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-e9d8868185
--- Additional comment from Fedora Update System on 2019-12-07 02:18:02 UTC ---
container-selinux-2.123.0-2.fc30, selinux-policy-3.14.3-53.fc30 has been pushed to the Fedora 30 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-e9d8868185
--- Additional comment from Fedora Update System on 2019-12-11 01:32:20 UTC ---
container-selinux-2.123.0-2.fc30, selinux-policy-3.14.3-53.fc30 has been pushed to the Fedora 30 stable repository. If problems still persist, please make note of it in this bug report.
--- Additional comment from Hicks on 2020-09-15 12:13:00 UTC ---
same with CentOS 8.2.2004.
Here is the debug:
----
type=AVC msg=audit(09/15/2020 14:07:58.824:201) : avc: denied { read } for pid=13210 comm=swanctl name=charon dev="dm-0" ino=672929 scontext=system_u:system_r:ipsec_mgmt_t:s0 tcontext=system_u:object_r:ipsec_conf_file_t:s0 tclass=dir permissive=1
----
type=AVC msg=audit(09/15/2020 14:07:58.880:202) : avc: denied { write } for pid=13210 comm=swanctl name=charon.vici dev="tmpfs" ino=56249 scontext=system_u:system_r:ipsec_mgmt_t:s0 tcontext=system_u:object_r:var_run_t:s0 tclass=sock_file permissive=1
I couldnt start the strongswan service:
Sep 15 14:01:15 prgvpn1 swanctl[7264]: no files found matching '/etc/strongswan/strongswan.conf'
Sep 15 14:01:15 prgvpn1 swanctl[7264]: abort initialization due to invalid configuration
Sep 15 14:01:15 prgvpn1 systemd[1]: strongswan.service: Control process exited, code=exited status=64
Sep 15 14:01:15 prgvpn1 charon-systemd[7247]: SIGTERM received, shutting down
--- Additional comment from Zdenek Pytela on 2020-09-15 12:50:05 UTC ---
This bugzilla was created for Fedora and the policy is updated now in all supported Fedora versions. If you need the same permissions in another OS, please create a new bz.
--- Additional comment from Hicks on 2020-09-15 20:44:31 UTC ---
(In reply to Zdenek Pytela from comment #15)
> This bugzilla was created for Fedora and the policy is updated now in all
> supported Fedora versions. If you need the same permissions in another OS,
> please create a new bz.
I'll try to figure out how to do it :)
--- Additional comment from Zdenek Pytela on 2020-09-15 21:54:38 UTC ---
In the bz header and footer there is a set of icons, you can choose to clone or light-weight copy.
--- Additional comment from Philip Prindeville on 2020-10-17 02:26:33 UTC ---
(In reply to Hicks from comment #14)
> same with CentOS 8.2.2004.
>
> Here is the debug:
>
> ----
> type=AVC msg=audit(09/15/2020 14:07:58.824:201) : avc: denied { read } for
> pid=13210 comm=swanctl name=charon dev="dm-0" ino=672929
> scontext=system_u:system_r:ipsec_mgmt_t:s0
> tcontext=system_u:object_r:ipsec_conf_file_t:s0 tclass=dir permissive=1
> ----
> type=AVC msg=audit(09/15/2020 14:07:58.880:202) : avc: denied { write }
> for pid=13210 comm=swanctl name=charon.vici dev="tmpfs" ino=56249
> scontext=system_u:system_r:ipsec_mgmt_t:s0
> tcontext=system_u:object_r:var_run_t:s0 tclass=sock_file permissive=1
>
> I couldnt start the strongswan service:
>
> Sep 15 14:01:15 prgvpn1 swanctl[7264]: no files found matching
> '/etc/strongswan/strongswan.conf'
> Sep 15 14:01:15 prgvpn1 swanctl[7264]: abort initialization due to invalid
> configuration
> Sep 15 14:01:15 prgvpn1 systemd[1]: strongswan.service: Control process
> exited, code=exited status=64
> Sep 15 14:01:15 prgvpn1 charon-systemd[7247]: SIGTERM received, shutting down
Yup, seeing this too.
What does the .te look like to fix this?
Comment 1Philip Prindeville
2020-10-19 23:33:24 UTC
Please port this fix to CentOS.
Comment 2Philip Prindeville
2020-11-05 03:06:55 UTC
Can we get an ETA on this? It's been fixed in Fedora, so most of the investigation has already been done.
Since a VPN concentrator is, in the majority of cases, sitting on a public network, this is a machine that needs to be well-defended. Having to run in Permissive mode until this is fixed is weakening our defense-in-depth.
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory (selinux-policy bug fix and enhancement update), and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.
https://access.redhat.com/errata/RHBA-2021:1639