Why is snapd accessing TLS certificates?

Why is snapd accessing TLS certificates?

SELinux is preventing snapd from open access on the file /etc/pki/tls/certs/Deutsche_Telekom_Root_CA_2.pem.

Because most SSL/TLS/HTTPS clients connections require CA certificates in order to function properly? The simplest example I can come up with:

  1. Web browser connects to HTTPS site.
  2. HTTPS server sends a server certificate, one of the fields in it is the Issuer.
  3. Web browser looks up the issuer in the TLS files.
  4. If it finds a match it continues to the web site.

If you want better answers, provide more details.

On my Fedora systems I use SyncThing in a snap because there is no flatpak. The snap is provided by a 3rd party as the official SyncThing snap support was discontinued. It works great, my SyncThing is sandboxed and running as non-root for risk mitigation.

$ snap list
Name                    Version   Rev    Tracking       Publisher      Notes
core20                  20220826  1623   latest/stable  canonicalâś“     base
snapd                   2.57.2    17029  latest/stable  canonicalâś“     snapd
syncthing-arubislander  1.20.4    28     latest/stable  arub-islander  -

I have never had any SELinux issues with it. IIRC, I don’t think it uses CA certificates for TLS though. I think it uses self-signed ones.

Thanks, I recently upgraded from F35 to F36 and noticed the SEL warning, so I’m very confused why something that wasn’t complaining in F35 would suddenly be complaining in F36. Seems weird.

I don’t install snaps or flatpaks when there’s an rpm available. I’m a little surpised at what’s listed in there. I run KDE, so I’m confused now about gnome being a snap. :grimacing:

Name                    Version                     Rev    Tracking       Publisher   Notes
acrordrdc               2021.007.20091              62     latest/stable  mmtrt       -
bare                    1.0                         5      latest/stable  canonicalâś“  base
core18                  20220831                    2566   latest/stable  canonicalâś“  base
gnome-3-28-1804         3.28.0-19-g98f9e67.98f9e67  161    latest/stable  canonicalâś“  -
gtk-common-themes       0.1-81-g442e511             1535   latest/stable  canonicalâś“  -
snapd                   2.57.2                      17029  latest/stable  canonicalâś“  snapd
wine-platform-6-stable  6.0.4                       19     latest/stable  mmtrt       -
wine-platform-runtime   v1.0                        316    latest/stable  mmtrt       -

It is the nature of running snaps. They pull in the runtimes they need to operate. Apparently, gnome is one of those requirements.

I haven’t tried snaps in a long-time. Are they really sandboxed on Fedora? For some reason I thought that snaps relied on apparmor for security sandboxing.

There have been some updates to the selinux policies and thus older systems that have not yet received a relabel to match the newer policies may complain.
The fix seems to be to do either sudo touch /.autorelabel which will relabel the secontext for the whole system at the next boot, or sudo restorecon -r / which will do the same thing for the running system (but could potentially interfere with a running process).

1 Like
$ dnf info snap-confine
Last metadata expiration check: 0:00:04 ago on Mon 03 Oct 2022 08:03:11 PM EDT.
Installed Packages
Name         : snap-confine
Version      : 2.56.2
Release      : 4.fc36
Architecture : x86_64
Size         : 9.0 M
Source       : snapd-2.56.2-4.fc36.src.rpm
Repository   : @System
From repo    : updates
Summary      : Confinement system for snap applications
URL          : https://github.com/snapcore/snapd
License      : GPLv3
Description  : This package is used internally by snapd to apply confinement to
             : the started snap applications.

https://packages.fedoraproject.org/pkgs/snapd/snap-confine/index.html

1 Like

That was it. Thank you.