Description of problem: Seems that these help: require { type tun_tap_device_t; type ipsec_mgmt_t; type ipsec_conf_file_t; class file map; class tun_socket create; class chr_file { ioctl open read write }; } #============= ipsec_mgmt_t ============== allow ipsec_mgmt_t ipsec_conf_file_t:file map; allow ipsec_mgmt_t self:tun_socket create; allow ipsec_mgmt_t tun_tap_device_t:chr_file ioctl; allow ipsec_mgmt_t tun_tap_device_t:chr_file { open read write }; Version-Release number of selected component (if applicable): selinux-policy-3.14.4-49.fc31.noarch How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Hi Strongswan maintainers, Did you introduced any features in strongswan 5.8 ? Thanks, Lukas.
This is getting urgent. Now in Fedora32 and RHEL 8 with new Strongswan 5.8.
Is Fedora 31 affected too? Any AVC denials in the logs? This could be the same as bug 1831669.
On Centos Stream I see: $ ausearch -ts 11:10 | audit2why | egrep '(ipse|swan)' type=AVC msg=audit(1589364735.093:508): avc: denied { search } for pid=4993 comm="swanctl" name="strongswan" dev="dm-1" ino=34813118 scontext=system_u:system_r:ipsec_mgmt_t:s0 tcontext=system_u:object_r:ipsec_conf_file_t:s0 tclass=dir permissive=0 type=AVC msg=audit(1589364788.123:526): avc: denied { search } for pid=5162 comm="swanctl" name="strongswan" dev="dm-1" ino=34813118 scontext=system_u:system_r:ipsec_mgmt_t:s0 tcontext=system_u:object_r:ipsec_conf_file_t:s0 tclass=dir permissive=0 $ find /etc/ -inum 34813118 /etc/strongswan $ ausearch ... ... #============= ipsec_mgmt_t ============== allow ipsec_mgmt_t ipsec_conf_file_t:dir search; That is after silent denials disabled.
And this: module strongswan-pawel 1.0; require { type ipsec_mgmt_t; type ipsec_conf_file_t; class dir { getattr open read search }; class file map; } #============= ipsec_mgmt_t ============== #!!!! This avc is allowed in the current policy allow ipsec_mgmt_t ipsec_conf_file_t:dir { getattr open read search }; #!!!! This avc can be allowed using the boolean 'domain_can_mmap_files' allow ipsec_mgmt_t ipsec_conf_file_t:file map; on Centos Stream fixes the problem for me. But yes, it seems that default fcontext (reg bug 1831669) could use some looking into it. ipsec config VS swanct config & default lables: - everything in /etc/strongswan/ipsec.d gets: ipsec_key_file_t (which is probably not good) - everything in /etc/strongswan/swanctl/ gets: ipsec_conf_file_t (including pubkey, private folders)
On Centos Stream: selinux-policy-3.14.3-41.el8.noarch
This bug is tracked against Fedora. Please provide the AVC audit messages seen in Fedora if you can, as the policy can be different. Sending back to selinux-policy as none of the strongswan maintainers can offer an idea of what went wrong. I see the same selinux contexts in /etc/strongswan as reported in comment 5. (In reply to Lukas Vrabec from comment #1) > > Did you introduced any features in strongswan 5.8 ? As far as I can see, there were only updates to the latest version.
I did start with Fedora and I filed it for F31 and showed a set of rules which helped me on F31. Cannot fully investigate F32 just yet but it looks like it's there.
These permissions are present in Fedoras including F31: allow ipsec_mgmt_t ipsec_conf_file_t:dir { getattr open read search }; This one needs to be added: allow ipsec_mgmt_t ipsec_conf_file_t:file map;; > - everything in /etc/strongswan/ipsec.d gets: ipsec_key_file_t (which is probably not good) This directory contains directories with keys, why do you thing this is wrong? We can possibly change this to enumeration as it is used for /etc/strongswan/swanctl/* > - everything in /etc/strongswan/swanctl/ gets: ipsec_conf_file_t (including pubkey, private folders) This hss changed in the current policy.
I understand that '/etc/strongswan/ipsec.d' is rather for config files, something with 'include ipsec.d/my.conf' in /etc/strongswan/ipsec.conf. And then strongswan rpm package creates a few subfolders: aacerts acerts ... private Which are, I bevlieve specifically for keys & certs. But! Strongswan with version >5.8 do not use "ipsec" anymore and instead runs/needs swanctl configuration. So it's "/etc/strongswan/swanctl/" which really matters now. (which similarly has subfolders for specific stuff and itself is a place holder for config files, I believe)
(In reply to lejeczek from comment #10) > I understand that '/etc/strongswan/ipsec.d' is rather for config files, > something with 'include ipsec.d/my.conf' in /etc/strongswan/ipsec.conf. > And then strongswan rpm package creates a few subfolders: > aacerts > acerts > ... > private > > Which are, I bevlieve specifically for keys & certs. That's how I understand it, too. > But! Strongswan with version >5.8 do not use "ipsec" anymore and instead > runs/needs swanctl configuration. So it's "/etc/strongswan/swanctl/" which > really matters now. (which similarly has subfolders for specific stuff and > itself is a place holder for config files, I believe) Given this information, I won't change the file context list along with /etc/strongswan/swanctl/*, I'd actually rather remove /etc/(strongswan)?/ipsec\.d(/.*)? gen_context(system_u:object_r:ipsec_key_file_t,s0) what do you think? For the record, this is the strongswan fc list: /etc/strongswan/swanctl/bliss/(/.*)? gen_context(system_u:object_r:ipsec_key_file_t,s0) /etc/strongswan/swanctl/ecdsa(/.*)? gen_context(system_u:object_r:ipsec_key_file_t,s0) /etc/strongswan/swanctl/pkcs.* gen_context(system_u:object_r:ipsec_key_file_t,s0) /etc/strongswan/swanctl/private(/.*)? gen_context(system_u:object_r:ipsec_key_file_t,s0) /etc/strongswan/swanctl/pubkey(/.*)? gen_context(system_u:object_r:ipsec_key_file_t,s0) /etc/strongswan/swanctl/rsa(/.*)? gen_context(system_u:object_r:ipsec_key_file_t,s0) /etc/strongswan/swanctl/x509.* gen_context(system_u:object_r:ipsec_key_file_t,s0) The /etc/strongswan/swanctl dir itself inherits context from its parent.
That would look right. Currently in - Fedora selinux-policy-3.14.5-39.fc32.noarch system_u:object_r:ipsec_conf_file_t:s0 bliss system_u:object_r:ipsec_conf_file_t:s0 conf.d system_u:object_r:ipsec_key_file_t:s0 ecdsa system_u:object_r:ipsec_key_file_t:s0 pkcs12 system_u:object_r:ipsec_key_file_t:s0 pkcs8 system_u:object_r:ipsec_key_file_t:s0 private system_u:object_r:ipsec_key_file_t:s0 pubkey system_u:object_r:ipsec_key_file_t:s0 rsa system_u:object_r:ipsec_conf_file_t:s0 swanctl.conf system_u:object_r:ipsec_key_file_t:s0 x509 system_u:object_r:ipsec_key_file_t:s0 x509aa system_u:object_r:ipsec_key_file_t:s0 x509ac system_u:object_r:ipsec_key_file_t:s0 x509ca system_u:object_r:ipsec_key_file_t:s0 x509crl system_u:object_r:ipsec_key_file_t:s0 x509ocsp - Centos selinux-policy-3.14.3-41.el8.noarch system_u:object_r:ipsec_conf_file_t:s0 bliss system_u:object_r:ipsec_conf_file_t:s0 conf.d system_u:object_r:ipsec_conf_file_t:s0 ecdsa system_u:object_r:ipsec_conf_file_t:s0 pkcs12 system_u:object_r:ipsec_conf_file_t:s0 pkcs8 system_u:object_r:ipsec_conf_file_t:s0 private system_u:object_r:ipsec_conf_file_t:s0 pubkey system_u:object_r:ipsec_conf_file_t:s0 rsa system_u:object_r:ipsec_conf_file_t:s0 swanctl.conf system_u:object_r:ipsec_conf_file_t:s0 x509 system_u:object_r:ipsec_conf_file_t:s0 x509aa system_u:object_r:ipsec_conf_file_t:s0 x509ac system_u:object_r:ipsec_conf_file_t:s0 x509ca system_u:object_r:ipsec_conf_file_t:s0 x509crl system_u:object_r:ipsec_conf_file_t:s0 x509ocsp and it seems that Fedora systemd has no problems now nor has "swanctl" tool set.
In the end I've decided to submit a minimalistic Fedora PR to address the issue: https://github.com/fedora-selinux/selinux-policy/pull/358
commit 4ff4f220ac14dc28bec03da22d7ce4c5ca2262ca (HEAD -> rawhide, origin/rawhide) Author: Zdenek Pytela <zpytela> Date: Fri May 29 19:44:13 2020 +0200 Allow ipsec_mgmt_t mmap ipsec_conf_file_t files Resolves: rhbz#1808530
FEDORA-2020-2f43f173b0 has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2020-2f43f173b0
FEDORA-2020-2f43f173b0 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-2f43f173b0` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-2f43f173b0 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
selinux-policy-3.14.4-53.fc31 has been pushed to the Fedora 31 stable repository. If problems still persist, please make note of it in this bug report.
Can this be pushed back into an older policy or newer(fixed) policy made available for RHEL/Centos 8. On Centos with "selinux-policy-3.14.3-41.el8_2.6.noarch" I still get: type=AVC msg=audit(1603705742.981:496): avc: denied { siginh } for pid=34923 comm="charon-systemd" scontext=system_u:system_r:init_t:s0 tcontext=system_u:system_r:unconfined_service_t:s0 tclass=process permissive=0 Was caused by: Missing type enforcement (TE) allow rule. You can use audit2allow to generate a loadable module to allow this access. type=AVC msg=audit(1603705743.045:497): avc: denied { search } for pid=34943 comm="swanctl" name="strongswan" dev="dm-0" ino=67234122 scontext=system_u:system_r:ipsec_mgmt_t:s0 tcontext=system_u:object_r:ipsec_conf_file_t:s0 tclass=dir permissive=0 Was caused by: Missing type enforcement (TE) allow rule. You can use audit2allow to generate a loadable module to allow this access. Above is for systemd failing to start strongswan daemon. Thanks.