Can't read secrets because of AppArmor

[Andrew]

Hello!

I run into issue on Ubuntu 18.04.3 LTS:

charon[4711]: 00[CFG] expanding file expression '/etc/ipsec.secrets.d/*.secrets' failed

I use strace to find out it have no permission to read /etc/ipsec.secrets.d/. AppArmor configuration denies such access, but allow to read /etc/ipsec.*.secrets files (see full profile below).

My proposals:

• save secrets into /etc/ipsec.*.secrets files
  OR
• add AppArmor configuration steps

# ------------------------------------------------------------------
#
#   Copyright (C) 2016 Canonical Ltd.
#
#   This program is free software; you can redistribute it and/or
#   modify it under the terms of version 2 of the GNU General Public
#   License published by the Free Software Foundation.
#
#   Author: Jonathan Davies <[e-mail]>
#           Ryan Harper <[e-mail]>
#
# ------------------------------------------------------------------

#include <tunables/global>

/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,

  # libcharon-extra-plugins: xauth-pam
  capability audit_write,

  # libstrongswan-standard-plugins: agent
  capability dac_override,

  capability net_admin,
  capability net_raw,

  network,
  network raw,

  /bin/dash                 rmPUx,

  # libchron-extra-plugins: kernel-libipsec
  /dev/net/tun              rw,

  /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,

  # 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>
}

[Imran Iqbal]

Thanks for the report, @baznikin. Let's ask @daks for some opinions about this.

[Éric Veiras Galisson]

A quick answer with ideas (without digging further):

• formula was developed and tested on Debian, but it looks like ubuntu 1804 is in travis test matrix https://github.com/saltstack-formulas/strongswan-formula/blob/master/.travis.yml#L70, maybe containers are not sufficient to test this kind of thing
• I don't really like the idea of having a lot of /etc/ipsec.*.secrets files filling the /etc directory and prefer to have them in a single directory, that's why it was developed that way
• I think we can find a way to make the 'dropins' naming customisable, or completely optional so you put all your secrets in one file
• concerning AppArmor, do you talk about documentation about configuring it, or someway to add the directory to is config with salt?

[Éric Veiras Galisson]

@baznikin are you still affected by this problem? Did you find a solution to it? Do you have any opinion on what I proposed earlier?

[Michael Feger]

we ran into the same issue on debian/buster. We have added the following state:

/etc/apparmor.d/local/usr.lib.ipsec.charon:
  file.managed:
    - source: salt://...../files/apparmor-usr.lib.ipsec.charon
    - user: root
    - group: root
    - mode: 0644
    - watch_in:
      - service: /etc/apparmor.d/local/usr.lib.ipsec.charon

  service.running:
    - reload: True
    - name: apparmor

/etc/apparmor.d/local/usr.lib.ipsec.charon now contains

  /etc/ipsec.secrets.d/     r,
  /etc/ipsec.secrets.d/**   r,

no need to change upstream /etc/apparmor.d/usr.lib.ipsec.charon

This works now with debian/buster, not sure how to patch the formula so it does not break other osfamilies...

BTW: in strongswan/config.sls directory permissions of /etc/ipsec.secrets.d are set to '0600' but should be '0700' (or even '0750' - otherwise strongswan.group does not make sense)

[Éric Veiras Galisson]

An update on this issue: I got the same problem on Debian Bullseye and adding the file provided by @realbodo above has solved it.

[Éric Veiras Galisson]

I created a PR to implement an optional state to add AppArmor rules. If you have any possibilities to test it, please do and make any comments on the PR itself, thanks