NM Gnome applet sends path to charon, which might be unreachable to system daemon

[pemensik]

System (please complete the following information):

• OS: Fedora 34
• Kernel version (if applicable): 5.13.12-200.fc34.x86_64
• strongSwan version(s): strongswan-5.9.4-1.fc34.x86_64 NetworkManager-strongswan-1.5.2-1.fc34.x86_64
• Tested/confirmed with the latest version: yes
  Describe the bug
  Fedora has SELinux security layer enabled by default. It prevents even services running under root from some privileges, which root usually has. For example it prevents system services to read user directories, when they have no need for that.

To Reproduce
Steps to reproduce the behavior:

1. have SELinux enabled and in enforcing mode
2. configure new strongswan VPN from UI
3. have certificate stored inside your home
4. choose user certificate as a way to validate server and/or client

Expected behavior
Client part of the UI plugin would read certificate file as it is. It would send the contents to charon-nm service over d-bus. It would not have to read any file from external directories, such as /home. Form x509 from certificate data, not file path. Both user and charon would access only data allowed by them.

Logs/Backtraces

No log, just bug #1932473 report on Red Hat bugzilla.

Additional context
Some discussion were done about it on: https://ask.fedoraproject.org/t/cannot-connect-to-ikev2-vpn-on-fedora-33-no-trusted-rsa-public-key-found/

[tobiasbrunner]

Thanks for the report. There is a duplicate issue in the old bug tracker. I think passing the certificate/key (the CA/gateway cert too) from the auth dialog might be possible, but it would require some major refactoring in the code of that and that of charon-nm for which I currently don't have the resources.

Authentication via ssh-agent is probably also not possible, right? We pass the SSH_AUTH_SOCK value to the daemon for that. The agent plugin that uses it requests CAP_DAC_OVERRIDE to access it, which probably doesn't help here. I don't see an easy workaround for that.

[pemensik]

I just learned from NM guys on IRC, that ~/.cert directory has different SELinux context. It should be available to charon-nm if user saves certificates inside that directory. chmod +x $HOME might be needed.

[tobiasbrunner]

I see, great. So should we close this?

[pemensik]

Please wait, I were not able to confirm it works yet. Do you know any strongswan server I could use for testing, without configuring my own service somewhere?

[tobiasbrunner]

You don't really need an actual server to test this as the inability to read the certificate/key will cause an error before initiating the connection.

[Jmennius]

Fedora, since strongswan version 5.9.0-4 (issue) builds strongstan with --with-capabilities=libcap which makes charon drop capabilities at startup, including cap_dac_override, cap_dac_read_search.
So since then, charon-nm should have normal (nonprivileged) access to files as root user/group.
In my case, I was missing search permission for root group on my home directory.

I do not think we should close this issue - I would make it a starting point for implementation to allow files to be passed at runtime.

@tobiasbrunner what agent plugin are you talking about (just a link should be enough, thanks)?

[pemensik]

Oh, okay. At least for readable cert stored in ~/.cert/, no failure is reported. I had to enable +x on my home.

I had to call restorecon -R ~/.cert after copying there original file. It reports failures in home directly:

ls -lZ ~/.cert
-rw-r--r--. 1 pemensik pemensik unconfined_u:object_r:home_cert_t:s0 5628  9. lis 17.08 vps.pem

# sudo ausearch -i -ts recent -m avc -m user_avc -m selinux_err
type=AVC msg=audit(9.11.2021 17:04:40.541:66986) : avc:  denied  { map } for  pid=1123041 comm=charon-nm path=/home/pemensik/turris.yml dev="dm-3" ino=238681 scontext=system_u:system_r:ipsec_t:s0 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file permissive=1 
----
type=AVC msg=audit(9.11.2021 17:10:51.932:67042) : avc:  denied  { getattr } for  pid=1123604 comm=charon-nm path=/dev/tpmrm0 dev="devtmpfs" ino=138 scontext=system_u:system_r:ipsec_t:s0 tcontext=system_u:object_r:tpm_device_t:s0 tclass=chr_file permissive=1 
----
type=AVC msg=audit(9.11.2021 17:13:21.813:67109) : avc:  denied  { read } for  pid=1123604 comm=charon-nm name=vps.pem dev="dm-3" ino=158306 scontext=system_u:system_r:ipsec_t:s0 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file permissive=1 
----
type=AVC msg=audit(9.11.2021 17:13:21.813:67110) : avc:  denied  { open } for  pid=1123604 comm=charon-nm path=/home/pemensik/vps.pem dev="dm-3" ino=158306 scontext=system_u:system_r:ipsec_t:s0 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file permissive=1 
----
type=AVC msg=audit(9.11.2021 17:13:21.814:67111) : avc:  denied  { map } for  pid=1123604 comm=charon-nm path=/home/pemensik/vps.pem dev="dm-3" ino=158306 scontext=system_u:system_r:ipsec_t:s0 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file permissive=1 

But it seems to me build without cap_dac_read_search is unusable this way for any private key. Small improvement might be running daemon under selected group. But it would still allow any member reading contents of other's secret.

[tobiasbrunner]

Fedora, since strongswan version 5.9.0-4 (issue) builds strongstan with --with-capabilities=libcap which makes charon drop capabilities at startup, including cap_dac_override, cap_dac_read_search.

Unless it was patched out, it should keep those (plugins can request capabilities they require and these are then not dropped).

I would make it a starting point for implementation to allow files to be passed at runtime.

They are passed at runtime either way, just either as data blob or as file path.

what agent plugin are you talking about (just a link should be enough, thanks)?

Don't have a link except the source.