Bug 1815983 - SELinux is preventing starter from 'connectto' accesses on the unix_stream_socket /run/strongswan/charon.ctl.
Summary: SELinux is preventing starter from 'connectto' accesses on the unix_stream_so...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy
Version: 31
Hardware: x86_64
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Zdenek Pytela
QA Contact: Milos Malik
URL:
Whiteboard: abrt_hash:1e0825c748c41a004ad9e5a5d72...
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-03-23 04:37 UTC by Raman Gupta
Modified: 2020-06-05 02:39 UTC (History)
7 users (show)

Fixed In Version: selinux-policy-3.14.4-52.fc31
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-06-05 02:39:59 UTC
Type: ---


Attachments (Terms of Use)

Description Raman Gupta 2020-03-23 04:37:26 UTC
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

Comment 1 Raman Gupta 2020-03-23 04:43:51 UTC
# 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

Comment 2 Zdenek Pytela 2020-03-23 15:11:05 UTC
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@redhat.com> - 5.8.2-2
- Use /run/strongswan as rundir to support strongswans in namespaces

Comment 3 Zdenek Pytela 2020-03-23 17:52:11 UTC
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.

Comment 4 Lukas Vrabec 2020-03-23 18:59:50 UTC
commit a9a124efb4b03f40c01b66a73deb59f364281f86 (HEAD -> rawhide, origin/rawhide)
Author: Zdenek Pytela <zpytela@redhat.com>
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

Comment 5 Raman Gupta 2020-03-23 19:44:28 UTC
(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.

Comment 6 Zdenek Pytela 2020-03-24 17:02:52 UTC
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.

Comment 7 Raman Gupta 2020-03-24 17:21:01 UTC
(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.

Comment 8 Fedora Update System 2020-05-20 13:47:36 UTC
FEDORA-2020-6d33cc238c has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2020-6d33cc238c

Comment 9 Fedora Update System 2020-05-21 04:16:15 UTC
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.

Comment 10 Fedora Update System 2020-06-05 02:39:59 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.