Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Bug#1032110: Apparmor denies access to /etc/ipsec.secrets.d/
69 views
Skip to first unread message
James Lownie
Feb 28, 2023, 1:00:04 AM2/28/23
to
Version: 5.9.1-1+deb11u3
Package: strongswan-charon
Version: 5.9.1-1+deb11u3
Severity: normal
X-Debbugs-Cc: none
Dear maintainer,
I ran into a problem using Strongswan which looks like a bug to me. I'm not sure if its in strongswan-charon or in Apparmor but I fixed it by editing /etc/apparmor.d/usr.lib.ipsec.charon which is strongswan-charon code, so I'm raising it here first.
The problem was that when I ran the command 'ipsec rereadsecrets' these messages appeared in syslog:
Feb 28 14:50:41 myhostname charon: 01[CFG] expanding file expression '/etc/ipsec.secrets.d/*' failed
Feb 28 14:50:41 myhostname kernel: [2262128.239395] audit: type=1400 audit(1677556241.557:15): apparmor="DENIED" operation="open" profile="/usr/lib/ipsec/charon" name="/etc/ipsec.secrets.d/" pid=49996 comm="charon" requested_mask="r" d
enied_mask="r" fsuid=0 ouid=0
Feb 28 14:50:41 myhostname kernel: [2262128.239405] audit: type=1400 audit(1677556241.557:16): apparmor="DENIED" operation="open" profile="/usr/lib/ipsec/charon" name="/etc/ipsec.secrets.d/99-netier_datacenter.secrets" pid=49996 comm="
charon" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
Incoming connections were then rejected:
Feb 28 14:46:57 myhostname charon: 14[CFG] selected peer config 'my_sa_name'
Feb 28 14:46:57 myhostname charon: 14[IKE] no shared key found for '192.168.XXX.0' - '192.168.XXX.0'
Feb 28 14:46:57 fw-cwp-dubbo charon: 14[IKE] received ESP_TFC_PADDING_NOT_SUPPORTED, not using ESPv3 TFC padding
Feb 28 14:46:57 fw-cwp-dubbo charon: 14[ENC] generating IKE_AUTH response 1 [ N(AUTH_FAILED) ]
I disabled this profile using aa-complain and verified that ipsec could read the secrets file and that the connection could be opened.
I then modified /etc/apparmor.d/usr.lib.ipsec.charon as follows, after which IPSec was able to load the secrets file and authenticate incoming connections:
+ # Site-specific additions and overrides. See local/README for details.
+ #include <local/usr.lib.ipsec.charon>
+ /etc/ipsec.secrets.d/ r,
+ /etc/ipsec.secrets.d/** r,
/etc/ipsec.conf r,
/etc/ipsec.secrets r,
/etc/ipsec.*.secrets r,
/etc/ipsec.d/ r,
/etc/ipsec.d/** r,
/etc/ipsec.d/crls/* rw,
/etc/opensc/opensc.conf r,
/etc/strongswan.conf r,
/etc/strongswan.d/ r,
/etc/strongswan.d/** r,
/etc/tnc_config r,
/proc/sys/net/core/xfrm_acq_expires w,
/run/charon.* rw,
/run/pcscd/pcscd.comm rw,
/usr/lib/ipsec/charon rmix,
/usr/lib/ipsec/imcvs/ r,
/usr/lib/ipsec/imcvs/** rm,
/usr/lib/*/opensc-pkcs11.so rm,
/var/lib/strongswan/* r,
/{,var/}run/systemd/notify w,
# allow self to read file descriptors (LP #1786250)
# restrict to our own process-ID as per apparmor vars
@{PROC}/@{pid}/fd/ r,
# for using the ha plugin (LP: #1773956)
@{PROC}/@{pid}/net/ipt_CLUSTERIP/ r,
@{PROC}/@{pid}/net/ipt_CLUSTERIP/* rw,
- # Site-specific additions and overrides. See local/README for details.
- #include <local/usr.lib.ipsec.charon>
- /etc/ipsec.secrets.d/ r,
- /etc/ipsec.secrets.d/** r,
}
-- System Information:
Debian Release: 11.6
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 5.10.0-21-amd64 (SMP w/4 CPU threads)
Locale: LANG=en_AU, LC_CTYPE=en_AU (charmap=ISO-8859-1), LANGUAGE=en_AU:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages strongswan-charon depends on:
ii debconf [debconf-2.0] 1.5.77
ii iproute2 5.10.0-4
ii libc6 2.31-13+deb11u5
ii libstrongswan 5.9.1-1+deb11u3
ii strongswan-libcharon 5.9.1-1+deb11u3
ii strongswan-starter 5.9.1-1+deb11u3
strongswan-charon recommends no packages.
strongswan-charon suggests no packages.
-- Configuration Files:
/etc/apparmor.d/usr.lib.ipsec.charon changed:
/usr/lib/ipsec/charon flags=(attach_disconnected) {
#include <abstractions/base>
#include <abstractions/nameservice>
#include <abstractions/authentication>
#include <abstractions/openssl>
#include <abstractions/p11-kit>
capability ipc_lock,
capability net_admin,
capability net_raw,
# allow priv dropping (LP: #1333655)
capability chown,
capability setgid,
capability setuid,
capability setpcap,
# libcharon-extra-plugins: xauth-pam
capability audit_write,
# libstrongswan-standard-plugins: agent
capability dac_override,
network,
network raw,
/{,usr/}bin/dash rmPUx,
# libcharon-extra-plugins: kernel-libipsec
/dev/net/tun rw,
# Site-specific additions and overrides. See local/README for details.
#include <local/usr.lib.ipsec.charon>
/etc/ipsec.secrets.d/ r,
/etc/ipsec.secrets.d/** r,
/etc/ipsec.conf r,
/etc/ipsec.secrets r,
/etc/ipsec.*.secrets r,
/etc/ipsec.d/ r,
/etc/ipsec.d/** r,
/etc/ipsec.d/crls/* rw,
/etc/opensc/opensc.conf r,
/etc/strongswan.conf r,
/etc/strongswan.d/ r,
/etc/strongswan.d/** r,
/etc/tnc_config r,
/proc/sys/net/core/xfrm_acq_expires w,
/run/charon.* rw,
/run/pcscd/pcscd.comm rw,
/usr/lib/ipsec/charon rmix,
/usr/lib/ipsec/imcvs/ r,
/usr/lib/ipsec/imcvs/** rm,
/usr/lib/*/opensc-pkcs11.so rm,
/var/lib/strongswan/* r,
/{,var/}run/systemd/notify w,
# allow self to read file descriptors (LP #1786250)
# restrict to our own process-ID as per apparmor vars
@{PROC}/@{pid}/fd/ r,
# for using the ha plugin (LP: #1773956)
@{PROC}/@{pid}/net/ipt_CLUSTERIP/ r,
@{PROC}/@{pid}/net/ipt_CLUSTERIP/* rw,
}
-------------------
Simon Deziel
Feb 28, 2023, 10:10:04 AM2/28/23
to
On 2023-02-28 00:44, James Lownie wrote:
> Version: 5.9.1-1+deb11u3
> Package: strongswan-charon
> Version: 5.9.1-1+deb11u3
> Severity: normal
> X-Debbugs-Cc: none
>
>
> Dear maintainer,
Hello James, I'm not maintainer but I've used strongswan with the
> Version: 5.9.1-1+deb11u3
> Package: strongswan-charon
> Version: 5.9.1-1+deb11u3
> Severity: normal
> X-Debbugs-Cc: none
>
>
> Dear maintainer,
Apparmor profiles.
> I ran into a problem using Strongswan which looks like a bug to me. I'm not sure if its in strongswan-charon or in Apparmor but I fixed it by editing /etc/apparmor.d/usr.lib.ipsec.charon which is strongswan-charon code, so I'm raising it here first.
/etc/apparmor.d/local/usr.lib.ipsec.charon as the "local" directory is
meant to have the rules the local admin wanted to add. The main profile
includes this file so your rules would still work.
> The problem was that when I ran the command 'ipsec rereadsecrets' these messages appeared in syslog:
>
> Feb 28 14:50:41 myhostname charon: 01[CFG] expanding file expression '/etc/ipsec.secrets.d/*' failed
> Feb 28 14:50:41 myhostname kernel: [2262128.239395] audit: type=1400 audit(1677556241.557:15): apparmor="DENIED" operation="open" profile="/usr/lib/ipsec/charon" name="/etc/ipsec.secrets.d/" pid=49996 comm="charon" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
> /etc/ipsec.secrets r,
> /etc/ipsec.*.secrets r,
> /etc/ipsec.d/ r,
> /etc/ipsec.d/** r,
In your case, maybe it would be simpler to move your secrets files
> /etc/ipsec.*.secrets r,
> /etc/ipsec.d/ r,
> /etc/ipsec.d/** r,
directly to /etc/ipsec.d/*.secrets or if you prefer inside a manually
created directory like /etc/ipsed.d/secrets/*.secrets.
This way, you wouldn't need to customize the Apparmor profile at all and
it would just work.
HTH,
Simon
Yves-Alexis Perez
Feb 28, 2023, 12:10:04 PM2/28/23
to
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On Tue, 2023-02-28 at 16:44 +1100, James Lownie wrote:
> I then modified /etc/apparmor.d/usr.lib.ipsec.charon as follows, after which
> IPSec was able to load the secrets file and authenticate incoming
> connections:
Hi James, thanks for the report. Just to be sure: you *only* moved the lines
from the end of the file to the top?
Regards,
- --
Yves-Alexis
-----BEGIN PGP SIGNATURE-----
iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmP+M/8ACgkQ3rYcyPpX
RFsi+gf+JXmA+xT5Zau+0HmVq6DtlRynpOpMmldyN9ntg2GdbYWP+e44E40vZuPZ
BWZ1nm2UwCOlKT5uzE7r7JDpKkHIF15LucBR5qwr3GJuP1apaxsxtWMfthORDLyJ
TER7qUlYv8vSTeHSVGZQsLLVaaB2JPIjo1cF6nmpCnV/CsfKxy9Pc0NSkUKb2U4G
thp3DQkBYVBZx9gzMgXDKjZyy3zvqTLxc3gLhqwfMd5VRjElMARtMkpFL+8s0rac
ybofdTcGi9ORL5ipiiQnbF3urJHrR/zDHJrZEBMpeEszdtPWHs9WoYtJiqZjwniA
/2RePmWB61iGiRWmxicD4gNY02jMng==
=Eup3
-----END PGP SIGNATURE-----
Hash: SHA256
On Tue, 2023-02-28 at 16:44 +1100, James Lownie wrote:
> I then modified /etc/apparmor.d/usr.lib.ipsec.charon as follows, after which
> IPSec was able to load the secrets file and authenticate incoming
> connections:
from the end of the file to the top?
Regards,
- --
Yves-Alexis
-----BEGIN PGP SIGNATURE-----
iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmP+M/8ACgkQ3rYcyPpX
RFsi+gf+JXmA+xT5Zau+0HmVq6DtlRynpOpMmldyN9ntg2GdbYWP+e44E40vZuPZ
BWZ1nm2UwCOlKT5uzE7r7JDpKkHIF15LucBR5qwr3GJuP1apaxsxtWMfthORDLyJ
TER7qUlYv8vSTeHSVGZQsLLVaaB2JPIjo1cF6nmpCnV/CsfKxy9Pc0NSkUKb2U4G
thp3DQkBYVBZx9gzMgXDKjZyy3zvqTLxc3gLhqwfMd5VRjElMARtMkpFL+8s0rac
ybofdTcGi9ORL5ipiiQnbF3urJHrR/zDHJrZEBMpeEszdtPWHs9WoYtJiqZjwniA
/2RePmWB61iGiRWmxicD4gNY02jMng==
=Eup3
-----END PGP SIGNATURE-----
Simon Deziel
Feb 28, 2023, 5:30:03 PM2/28/23
to
On 2023-02-28 17:12, James Lownie wrote:
> Hi Simon, thanks for the suggestion. I'm going to wait and see if other people can reproduce this before running any tests, this machine is now in production which makes things awkward. I would have thought putting the secrets in /etc/ipsec.secrets.d/ would just work given it was already in the profile as a directory with read access.
Hmm, I don't see such *directory* rule in salsa:
https://salsa.debian.org/debian/strongswan/-/blob/debian/master/debian/usr.lib.ipsec.charon#L47-51
Maybe you thought that "/etc/ipsec.*.secrets" covered your dir? If so,
that's not the case because Apparmor needs the trailing "/" to apply to
directories. So the rule "/etc/ipsec.*.secrets" only covers files with a
prefix of "ipsec." and a ".secrets" suffix.
HTH,
Simon
> Hi Simon, thanks for the suggestion. I'm going to wait and see if other people can reproduce this before running any tests, this machine is now in production which makes things awkward. I would have thought putting the secrets in /etc/ipsec.secrets.d/ would just work given it was already in the profile as a directory with read access.
Hmm, I don't see such *directory* rule in salsa:
https://salsa.debian.org/debian/strongswan/-/blob/debian/master/debian/usr.lib.ipsec.charon#L47-51
Maybe you thought that "/etc/ipsec.*.secrets" covered your dir? If so,
that's not the case because Apparmor needs the trailing "/" to apply to
directories. So the rule "/etc/ipsec.*.secrets" only covers files with a
prefix of "ipsec." and a ".secrets" suffix.
HTH,
Simon
Simon Deziel
Feb 28, 2023, 6:10:04 PM2/28/23
to
On 2023-02-28 17:42, James Lownie wrote:
> It's not in salsa but it was in my config file. Is it the case that my version of /etc/apparmor.d/usr.lib.ipsec.charon is different to the package version?
>
> I didn't modify that file manually (apart from moving the lines up in the file), I did deploy ipsec with an Ansible playbook but I just had a look through it and I don't think it modified it either.
I just downloaded the same package
(https://packages.debian.org/bullseye/strongswan) and double checked.
The Apparmor profile doesn't mention any "/etc/ipsec.secrets.d"
directory. Dunno what to tell you, sorry.
HTH.
Simon
> It's not in salsa but it was in my config file. Is it the case that my version of /etc/apparmor.d/usr.lib.ipsec.charon is different to the package version?
>
> I didn't modify that file manually (apart from moving the lines up in the file), I did deploy ipsec with an Ansible playbook but I just had a look through it and I don't think it modified it either.
I just downloaded the same package
(https://packages.debian.org/bullseye/strongswan) and double checked.
The Apparmor profile doesn't mention any "/etc/ipsec.secrets.d"
directory. Dunno what to tell you, sorry.
HTH.
Simon
James Lownie
Feb 28, 2023, 7:00:05 PM2/28/23
to
It sounds like the problem is at our end then, I will investigate further. Thanks for helping with this Simon.
--
Message protected by MailGuard: e-mail anti-virus, anti-spam and content filtering.https://www.mailguard.com.au/mg
Click here to report this message as spam:
https://console.mailguard.com.au/ras/24UkePOXmh/8Ecez7b7drcTGdw6LBjfx/5.5
Message protected by MailGuard: e-mail anti-virus, anti-spam and content filtering.https://www.mailguard.com.au/mg
Click here to report this message as spam:
https://console.mailguard.com.au/ras/24UkePOXmh/8Ecez7b7drcTGdw6LBjfx/5.5
Simon Deziel
Feb 28, 2023, 10:50:04 PM2/28/23
to
On 2023-02-28 18:37, James Lownie wrote:
> It sounds like the problem is at our end then, I will investigate further. Thanks for helping with this Simon.
Great, please let us know how it goes! Thanks
> It sounds like the problem is at our end then, I will investigate further. Thanks for helping with this Simon.
0 new messages