Hi,

It looks like the files in the audit logs have incorrect label. You can fix the labels with a single command:

  # /sbin/restorecon -Rv /etc/strongswan/swanctl

or setup the machine to relabel all filesystems on the next reboot:

  # fixfiles onboot

and reboot the system.

It would be useful to know how you got into this state: were the keys created on a different place on the filesystem, like some user's home directory, and then moved or copied with preservin attributes to the final destination?

Hi again,

(In reply to Zdenek Pytela from comment #1)
> It looks like the files in the audit logs have incorrect label. You can fix
> the labels with a single command:
> 
>   # /sbin/restorecon -Rv /etc/strongswan/swanctl
> 
> or setup the machine to relabel all filesystems on the next reboot:
> 
>   # fixfiles onboot
> 
> and reboot the system.

Hmmm, the previous settings seemed to work on previous Fedora versions. I tried
both approaches above and none the tunnel still goes through only if I completely
disable SELinux.

> It would be useful to know how you got into this state: were the keys
> created on a different place on the filesystem, like some user's home
> directory, and then moved or copied with preservin attributes to the final
> destination?

Yes, everything is imported from other systems, however I can no longer recall
if it was a home directory or any other location. The copying has no special flags
enabled, as default as possible.

Hi,

The cp command without any switches creates files so that they inherit context from the parent directory, so that the user_home_t type is not preserved. Did the directories exist previously?

Also, what it your selinux-policy package version? The private etc. directories have a different type since 3.14.5-37.

Hi,

(In reply to Zdenek Pytela from comment #3)
> The cp command without any switches creates files so that they inherit
> context from the parent directory, so that the user_home_t type is not
> preserved. Did the directories exist previously?

I see thanks for clarifying. If you mean all the directories listed in the
steps to reproduce above then yes - they were all precreated and and I
configured strongswan on a fresh Fedora 32 install. The only files I reused
are the swanctl config file and the public and private keys.

> Also, what it your selinux-policy package version? The private etc.
> directories have a different type since 3.14.5-37.

# dnf info selinux-policy
Last metadata expiration check: 0:00:09 ago on Thu 14 May 2020 02:06:50 PM EEST.
Installed Packages
Name         : selinux-policy
Version      : 3.14.5
Release      : 38.fc32
Architecture : noarch
Size         : 25 k
Source       : selinux-policy-3.14.5-38.fc32.src.rpm
Repository   : @System
From repo    : updates
Summary      : SELinux policy configuration
URL          : https://github.com/fedora-selinux/selinux-policy
License      : GPLv2+
Description  : SELinux Base package for SELinux Reference Policy - modular.
             : Based off of reference policy: Checked out revision  2.20091117

# dnf update selinux-policy
Last metadata expiration check: 0:00:26 ago on Thu 14 May 2020 02:09:11 PM EEST.
Dependencies resolved.
Nothing to do.
Complete!

I guess your last clue relates well to the problem.

Hi,

So with current version of strongswan and selinux policy, the swanctl/* directories have (should have) correct labels. If any files remain with incorrect type, the restorecon command as suggested before should relabel them. Next time, the strongswan service should start without reporting a denial.

Yes I thought the same but the SELinux blocked the tunnel also after a reboot. Do you need to see some log files from charon or similar? I could provide you with some if you want.

What happens if you run:

restorecon -Rvn /etc/strongswan/swanctl

With the -n switch, restorecon does not change the context.

You may also be hitting another problem, so please run ausearch to collect the audited denials. The complete steps are:

1) Open /etc/audit/rules.d/audit.rules file in an editor.
2) Remove following line if it exists:
-a task,never
3) Add following line at the end of the file:
-w /etc/shadow -p w
4) Reboot
5) Collect AVC denials:
  # ausearch -i -m avc,user_avc,selinux_err,user_selinux_err -ts boot

(In reply to Zdenek Pytela from comment #7)
> What happens if you run:
> 
> restorecon -Rvn /etc/strongswan/swanctl
> 
> With the -n switch, restorecon does not change the context.

This did not change things either but I collected the denials below.

> You may also be hitting another problem, so please run ausearch to collect
> the audited denials. The complete steps are:
> 
> 1) Open /etc/audit/rules.d/audit.rules file in an editor.
> 2) Remove following line if it exists:
> -a task,never
> 3) Add following line at the end of the file:
> -w /etc/shadow -p w
> 4) Reboot
> 5) Collect AVC denials:
>   # ausearch -i -m avc,user_avc,selinux_err,user_selinux_err -ts boot

This captured two denials, one at boot and one after performing `systemctl restart strongswan`, both seem similar:

type=PROCTITLE msg=audit(05/14/2020 22:32:47.070:187) : proctitle=/usr/sbin/swanctl --load-all --noprompt 
type=PATH msg=audit(05/14/2020 22:32:47.070:187) : item=0 name=/etc/strongswan/swanctl/private inode=4333518 dev=fd:00 mode=dir,750 ouid=root ogid=root rdev=00:00 obj=system_u:object_r:home_cert_t:s0 nametype=NORMAL cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 cap_frootid=0 
type=CWD msg=audit(05/14/2020 22:32:47.070:187) : cwd=/ 
type=SYSCALL msg=audit(05/14/2020 22:32:47.070:187) : arch=x86_64 syscall=openat success=no exit=EACCES(Permission denied) a0=0xffffff9c a1=0x7ffe0886fce0 a2=O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC a3=0x0 items=1 ppid=1 pid=1270 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=swanctl exe=/usr/sbin/swanctl subj=system_u:system_r:ipsec_mgmt_t:s0 key=(null) 
type=AVC msg=audit(05/14/2020 22:32:47.070:187) : avc:  denied  { read } for  pid=1270 comm=swanctl name=private dev="dm-0" ino=4333518 scontext=system_u:system_r:ipsec_mgmt_t:s0 tcontext=system_u:object_r:home_cert_t:s0 tclass=dir permissive=0 
----
type=PROCTITLE msg=audit(05/14/2020 22:33:54.089:319) : proctitle=/usr/sbin/swanctl --load-all --noprompt 
type=PATH msg=audit(05/14/2020 22:33:54.089:319) : item=0 name=/etc/strongswan/swanctl/private inode=4333518 dev=fd:00 mode=dir,750 ouid=root ogid=root rdev=00:00 obj=system_u:object_r:home_cert_t:s0 nametype=NORMAL cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 cap_frootid=0 
type=CWD msg=audit(05/14/2020 22:33:54.089:319) : cwd=/ 
type=SYSCALL msg=audit(05/14/2020 22:33:54.089:319) : arch=x86_64 syscall=openat success=no exit=EACCES(Permission denied) a0=0xffffff9c a1=0x7ffdeeb6ba30 a2=O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC a3=0x0 items=1 ppid=1 pid=2739 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=swanctl exe=/usr/sbin/swanctl subj=system_u:system_r:ipsec_mgmt_t:s0 key=(null) 
type=AVC msg=audit(05/14/2020 22:33:54.089:319) : avc:  denied  { read } for  pid=2739 comm=swanctl name=private dev="dm-0" ino=4333518 scontext=system_u:system_r:ipsec_mgmt_t:s0 tcontext=system_u:object_r:home_cert_t:s0 tclass=dir permissive=0 

Does this tell you more?

Thank you for gathering the data. It says the command is executed as expected, the path for the private directory is correct, but the directory has incorrect content, preventing swanctl from reading it.

You need to have selinux-policy-3.14.5-37 or newer for the directory to have the ipsec_key_file_t type.

  # matchpathcon /etc/strongswan/swanctl/private
/etc/strongswan/swanctl/private system_u:object_r:ipsec_key_file_t:s0
  # rpm -qa "selinux-policy*"
selinux-policy-targeted-3.14.5-38.fc32.noarch
selinux-policy-3.14.5-38.fc32.noarch

If the actual types do not match the ones in policy, restorecon will fix them:

  # /sbin/restorecon -Rv /etc/strongswan/swanctl
Relabeled /etc/strongswan/swanctl/private from system_u:object_r:home_cert_t:s0 to system_u:object_r:ipsec_key_file_t:s0
...

The home_cert_t type is assigned to ~/.cert or ~/.pki:

  # matchpathcon /home/user/.cert/cert1 /root/.cert/cert2
/home/user/.cert/cert1  unconfined_u:object_r:home_cert_t:s0
/root/.cert/cert2       system_u:object_r:home_cert_t:s0

All good points, however I have two troubles:

1) Using `restorecon` even in verbose mode did not lead to the desired change:

[pevogam@drogon ~]$ matchpathcon /etc/strongswan/swanctl/private
/etc/strongswan/swanctl/private	system_u:object_r:home_cert_t:s0
[pevogam@drogon ~]$ sudo /sbin/restorecon -Rv /etc/strongswan/swanctl
[pevogam@drogon ~]$ matchpathcon /etc/strongswan/swanctl/private
/etc/strongswan/swanctl/private	system_u:object_r:home_cert_t:s0

I guess this also explains why using restorecon before didn't fix the issue.

2) The folder `private` was precreated on Fedora 32 and I only placed the files
inside implying that the folder itself has been set like this unless some other
mechanism changed the attributes of the entire folder perhaps with the default
copy command as you explained.

Am I missing something?

1) Do you happen to have some custom rules or a policy module?

  # semanage fcontext -l -C
  # semodule -lfull|grep -v ^100

Are there any symlinks in the path?

  # namei -lx /etc/strongswan/swanctl/private

2) It may depend on installed packages order, but that's a guess, let's first wait for the point 1.

(In reply to Zdenek Pytela from comment #11)
> 1) Do you happen to have some custom rules or a policy module?

The only customization I performed was the additions to audit2allow additions above.

>   # semanage fcontext -l -C

This revealed two file context lines for "private" and "private/client_private_key.pem" paths with the dreaded "home_cert_t". I deleted
them using "semanage fcontext -d xxxxxx" and rerun the restorecon to obtain:

# sudo /sbin/restorecon -Rv /etc/strongswan/swanctl
Relabeled /etc/strongswan/swanctl/private from system_u:object_r:home_cert_t:s0 to system_u:object_r:ipsec_key_file_t:s0
Relabeled /etc/strongswan/swanctl/private/client_private_key.pem from unconfined_u:object_r:home_cert_t:s0 to unconfined_u:object_r:ipsec_key_file_t:s0

# sudo matchpathcon /etc/strongswan/swanctl/private
/etc/strongswan/swanctl/private	system_u:object_r:ipsec_key_file_t:s0

This seems to match your previous expectations.

>   # semodule -lfull|grep -v ^100

# semodule -lfull|grep -v ^100
400 local             pp         
200 flatpak           pp         
200 mysql             pp

> Are there any symlinks in the path?
> 
>   # namei -lx /etc/strongswan/swanctl/private

No symlinks:

namei -lx /etc/strongswan/swanctl/private
f: /etc/strongswan/swanctl/private
Dr-xr-xr-x root root /
drwxr-xr-x root root etc
drwx------ root root strongswan
drwxr-xr-x root root swanctl
drwxr-x--- root root private

> 2) It may depend on installed packages order, but that's a guess, let's
> first wait for the point 1.

With the above deletions I tried again and still no success. I looked for the audit reported error messages and I get:

type=PROCTITLE msg=audit(05/15/2020 20:57:05.686:343) : proctitle=/usr/sbin/swanctl --load-all --noprompt 
type=PATH msg=audit(05/15/2020 20:57:05.686:343) : item=0 name=/etc/strongswan/swanctl/private inode=4333518 dev=fd:00 mode=dir,750 ouid=root ogid=root rdev=00:00 obj=system_u:object_r:home_cert_t:s0 nametype=NORMAL cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 cap_frootid=0 
type=CWD msg=audit(05/15/2020 20:57:05.686:343) : cwd=/ 
type=SYSCALL msg=audit(05/15/2020 20:57:05.686:343) : arch=x86_64 syscall=openat success=no exit=EACCES(Permission denied) a0=0xffffff9c a1=0x7fff4444b960 a2=O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC a3=0x0 items=1 ppid=1 pid=2355 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=swanctl exe=/usr/sbin/swanctl subj=system_u:system_r:ipsec_mgmt_t:s0 key=(null) 
type=AVC msg=audit(05/15/2020 20:57:05.686:343) : avc:  denied  { read } for  pid=2355 comm=swanctl name=private dev="dm-0" ino=4333518 scontext=system_u:system_r:ipsec_mgmt_t:s0 tcontext=system_u:object_r:home_cert_t:s0 tclass=dir permissive=0 

I basically restarted the strongswan service to produce these messages.

There is something fishy. To recap:
- the custom context rules were removed
- the directory was relabeled
- the next startup of strongswan service reports the label of /etc/strongswan/swanctl/private is back

I'd suggest checking the service unit. Additionally, I'd also recommend removing the local module:

  # systemctl cat strongswan
  # semodule -X 400 -r local

(In reply to Zdenek Pytela from comment #13)
> There is something fishy. To recap:
> - the custom context rules were removed
> - the directory was relabeled
> - the next startup of strongswan service reports the label of
> /etc/strongswan/swanctl/private is back
> 
> I'd suggest checking the service unit. Additionally, I'd also recommend
> removing the local module:
> 
>   # systemctl cat strongswan
>   # semodule -X 400 -r local

I removed the local module and rebooted and the tunnel goes well now. Not sure what to conclude from this and what made it work. Do you think there is some useful info from the entire process we went through? Are the initial rights correct on a fresh Fedora install?

Hmmm, I tested this yesterday but it seems I was too fast to conclude again. Anyway, I don't want to be
taking more of your time unless we have something more specific. For now I can just add the exceptions
I did in the original post and wait for newer version of strongswan/selinux to see if this improves.

Hi,

Every package should work out of the box, without a need to have a change like permissions, all these should be reported on the component.

I only suspected some changes to the service unit, as functional changes may require to adjust the policy, or that possibly the audited denials were not from the latest attempts. For now, I am closing this bz, but feel free to reopen it or create a new one if the issue is back again. Please use selinux-policy-3.14.5-37 or newer to have all ipsec related updates.