Due to a recent update on Javascript code a full page refresh on your browser might be needed.
Bug 1773381 - SELinux is preventing swanctl from 'search' accesses on the directory strongswan.
Summary: SELinux is preventing swanctl from 'search' accesses on the directory strongs...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy
Version: 30
Hardware: x86_64
OS: Unspecified
medium
medium
Target Milestone: ---
Assignee: Zdenek Pytela
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: abrt_hash:0c0660b664ed853c2413f04f0d2...
: 1654285 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-11-17 23:44 UTC by Dan Callaghan
Modified: 2019-12-11 01:32 UTC (History)
10 users (show)

Fixed In Version: selinux-policy-3.14.3-53.fc30
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-12-11 01:32:20 UTC
Type: ---


Attachments (Terms of Use)

Description Dan Callaghan 2019-11-17 23:44:02 UTC
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

Comment 1 Zdenek Pytela 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.

Comment 2 Zdenek Pytela 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.

Comment 3 Zdenek Pytela 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.

Comment 4 Mikhail Zabaluev 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.

Comment 5 Lukas Vrabec 2019-11-26 13:51:57 UTC
commit 714d1efd828effaf180659eee341db16558763c5 (HEAD -> rawhide, origin/rawhide)
Author: Zdenek Pytela <zpytela@redhat.com>
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.

Comment 6 Zdenek Pytela 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.

Comment 7 Mikhail Zabaluev 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.

Comment 8 Mikhail Zabaluev 2019-11-28 06:55:20 UTC
*** Bug 1654285 has been marked as a duplicate of this bug. ***

Comment 9 Fedora Update System 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

Comment 10 Fedora Update System 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

Comment 11 Fedora Update System 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

Comment 12 Fedora Update System 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

Comment 13 Fedora Update System 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.


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