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.

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.

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.

(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.

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.

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.

(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.

*** Bug 1654285 has been marked as a duplicate of this bug. ***

FEDORA-2019-e9d8868185 has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-e9d8868185

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

FEDORA-2019-e9d8868185 has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-e9d8868185

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

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.

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

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.

(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 :)

In the bz header and footer there is a set of icons, you can choose to clone or light-weight copy.

(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?

I had this problem on Centos 8.2.2004 too.

Here is how i solved it:

dnf install checkpolicy
cat <<EOF >strongswan_fix.te
module strongswan_fix 1.0;

require {
        type ipsec_conf_file_t;
        type ipsec_mgmt_t;
        type var_run_t;
        class dir { getattr open read search };
        class file map;
        class lnk_file read;
        class sock_file write;
}

allow ipsec_mgmt_t ipsec_conf_file_t:dir { getattr open read search };
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;
EOF
checkmodule -M -m -o strongswan_fix.mod strongswan_fix.te
semodule_package -o strongswan_fix.pp -m strongswan_fix.mod
semodule -i strongswan_fix.pp