Request classic confinement for grype

Hello! Me again! No, you’re not seeing things, not deja vu. I have another request which follows on from the one about Syft. :pray: Okay, so maybe a tiny bit of deja vu. :smiley:

I intentionally didn’t do them both together, in case there were subtle differences, and to avoid confusion. This is a whole new request for a different application.

There will be some duplication here, though!

Hi all.

Sorry again, this is long.

Metadata

Grype

I’m requesting classic confinement for the Grype snap. Grype is a well-established, open-source, command-line utility Vulnerability scanner written in Go, from Anchore - my employer. I have registered the snap under my account as the team’s domain expert in snap packaging. :wink:

I’m publishing this with the intention of handing it over - or likely collaborating with - an official company snapcraft account under the control of our central IT department. That account does not exist yet and likely won’t until we prove the utility, benefit and minimal overhead of delivering this and the other applications as snaps, in addition to our existing release workflow. :sweat:

I have included automation to pull the latest stable releases of Grype, and automate publication in the store. The latest version in the yaml is v0.79.4 which is current.

Classic confinement

Grype’s primary purpose is to scan containers, images and arbitrary folders to generate a report of vulnerabilities. It can also be fed an SBOM (typically from Syft, but they’re standard formats, so could come from anywhere). We have no control or visibility over where Grype will be run and against what filesystems or Linux distributions our users use.

Further, Grype can be requested to write the vulnerability report to any arbitrary location on the filesystem for storage or forwarding as the developer or architect deems necessary.

I believe Grype fits the same category as Syft - as outlined in this comment

None of the supported or unsupported ‘known categories’ cover what syftgrype does. In the section ‘criteria’ for things that might need classic, I think this line covers it best: ‘access to files on the host outside the snap’s runtime (eg, /usr)’

Examples

For example, these are legitimate uses of Grype. Either scanning directories or image files in random locations. These are pretty straightforwardly non-functional when confined.

Note, this differs from Syft in that it displays known vulnerabilities in packages detected in the directory. Under the hood it uses Syft, as a bundled library.

(you may ignore the [0000] WARN lines)

$ snap run grype dir:/snap/core22/current/ 
 ✔ Vulnerability DB [updated]
 ✔ Indexed file system /snap/core22/1439
 ✔ Cataloged contents 0bb364a1df4912b90f320959ddac175a0ea326d02296212a31c798938ae03abf
   ├── ✔ Packages                        [38 packages]
   └── ✔ Executables                     [1,470 executables]
 ✔ Scanned for vulnerabilities     [73 vulnerability matches]
   ├── by severity: 3 critical, 25 high, 35 medium, 4 low, 0 negligible (6 unknown)
   └── by status:   24 fixed, 49 not-fixed, 0 ignored
[0000]  WARN no explicit name and version provided for directory source, deriving artifact ID from the given path (which is not ideal)
[0000]  WARN unable to access path="/snap/core22/1439/etc/polkit-1/localauthority": open /snap/core22/1439/etc/polkit-1/localauthority: permission denied
[0000]  WARN unable to access path="/snap/core22/1439/etc/ssl/private": open /snap/core22/1439/etc/ssl/private: permission denied
[0000]  WARN unable to access path="/snap/core22/1439/root": open /snap/core22/1439/root: permission denied
[0006]  WARN unable to access path="/snap/core22/1439/var/cache/ldconfig": open /snap/core22/1439/var/cache/ldconfig: permission denied
[0006]  WARN unable to access path="/snap/core22/1439/var/cache/private": open /snap/core22/1439/var/cache/private: permission denied
[0006]  WARN unable to access path="/snap/core22/1439/var/lib/polkit-1": open /snap/core22/1439/var/lib/polkit-1: permission denied
[0006]  WARN unable to access path="/snap/core22/1439/var/lib/private": open /snap/core22/1439/var/lib/private: permission denied
[0006]  WARN unable to access path="/snap/core22/1439/var/lib/snapd/void": open /snap/core22/1439/var/lib/snapd/void: permission denied
[0006]  WARN unable to access path="/snap/core22/1439/etc/ssl/private": open /snap/core22/1439/etc/ssl/private: permission denied
[0030]  WARN unable to determine linux distribution: unable to determine distro type

jinja2        3.0.3      3.1.3       python  GHSA-h5c8-rqwp-cp95  Medium
oauthlib      3.2.0      3.2.2       python  GHSA-3pgj-pg6c-r5p7  Medium
openssl       3.0.2                  binary  CVE-2024-5535        Critical
openssl       3.0.2                  binary  CVE-2022-2068        Critical
openssl       3.0.2                  binary  CVE-2022-1292        Critical
openssl       3.0.2                  binary  CVE-2023-5363        High
openssl       3.0.2                  binary  CVE-2023-4807        High
openssl       3.0.2                  binary  CVE-2023-0464        High
openssl       3.0.2                  binary  CVE-2023-0401        High
openssl       3.0.2                  binary  CVE-2023-0286        High
openssl       3.0.2                  binary  CVE-2023-0217        High
openssl       3.0.2                  binary  CVE-2023-0216        High
openssl       3.0.2                  binary  CVE-2023-0215        High
openssl       3.0.2                  binary  CVE-2022-4450        High
openssl       3.0.2                  binary  CVE-2022-3996        High
openssl       3.0.2                  binary  CVE-2022-3786        High
openssl       3.0.2                  binary  CVE-2022-3602        High
openssl       3.0.2                  binary  CVE-2022-3358        High
openssl       3.0.2                  binary  CVE-2022-1473        High
openssl       3.0.2                  binary  CVE-2024-0727        Medium
openssl       3.0.2                  binary  CVE-2023-6129        Medium
openssl       3.0.2                  binary  CVE-2023-5678        Medium
openssl       3.0.2                  binary  CVE-2023-3817        Medium
openssl       3.0.2                  binary  CVE-2023-2975        Medium
openssl       3.0.2                  binary  CVE-2023-2650        Medium
openssl       3.0.2                  binary  CVE-2023-1255        Medium
openssl       3.0.2                  binary  CVE-2023-0466        Medium
openssl       3.0.2                  binary  CVE-2023-0465        Medium
openssl       3.0.2                  binary  CVE-2022-4304        Medium
openssl       3.0.2                  binary  CVE-2022-4203        Medium
openssl       3.0.2                  binary  CVE-2022-2097        Medium
openssl       3.0.2                  binary  CVE-2022-1434        Medium
openssl       3.0.2                  binary  CVE-2022-1343        Medium
openssl       3.0.2                  binary  CVE-2024-4603        Unknown
openssl       3.0.2                  binary  CVE-2024-2511        Unknown
openssl       3.0.2                  binary  CVE-2023-6237        Unknown
pyjwt         2.3.0      2.4.0       python  GHSA-ffqj-6fqr-9h24  High
python        3.10.12                binary  CVE-2024-4030        High
python        3.10.12                binary  CVE-2024-0397        High
python        3.10.12                binary  CVE-2023-6597        High
python        3.10.12                binary  CVE-2023-36632       High
python        3.10.12                binary  CVE-2024-6923        Medium
python        3.10.12                binary  CVE-2024-0450        Medium
python        3.10.12                binary  CVE-2023-40217       Medium
python        3.10.12                binary  CVE-2023-27043       Medium
python        3.10.12                binary  CVE-2024-4032        Unknown
python        3.10.12                binary  CVE-2024-3219        Unknown
requests      2.25.1     2.31.0      python  GHSA-j8r2-6x86-q33q  Medium
requests      2.25.1     2.32.0      python  GHSA-9wx4-h78v-vm56  Medium
setuptools    59.6.0     65.5.1      python  GHSA-r9hx-vwmv-q579  High
setuptools    59.6.0     70.0.0      python  GHSA-cx63-2mw6-8hw5  High
urllib3       1.26.5     1.26.17     python  GHSA-v845-jxx5-vc9f  Medium
urllib3       1.26.5     1.26.18     python  GHSA-g4mx-q9vg-27p4  Medium
urllib3       1.26.5     1.26.19     python  GHSA-34jh-p97f-mpxf  Medium
util-linux    2.37.2                 binary  CVE-2022-0563        Medium
util-linux    2.37.2                 binary  CVE-2021-3996        Medium
util-linux    2.37.2                 binary  CVE-2021-3995        Medium
util-linux    2.37.2                 binary  CVE-2024-28085       Unknown
zipp          1.0.0      3.19.1      python  GHSA-jfmj-5v4g-7637  Medium
$ snap run grype dir:/srv/repo/snapcore/snapd
 ✔ Vulnerability DB [updated]
 ✔ Indexed file system /srv/repo/snapcore/snapd
 ✔ Cataloged contents f654a6fdb7d9fcbd6e09dbbb4643a1440479b64d05a7a4a00c8836171a112531
   ├── ✔ Packages                        [75 packages]
   └── ✔ Executables                     [13 executables]
 ✔ Scanned for vulnerabilities     [14 vulnerability matches]
   ├── by severity: 0 critical, 3 high, 11 medium, 0 low, 0 negligible
   └── by status:   14 fixed, 0 not-fixed, 0 ignored
[0000]  WARN no explicit name and version provided for directory source, deriving artifact ID from the given path (which is not ideal)
NAME                       INSTALLED                           FIXED-IN  TYPE       VULNERABILITY        SEVERITY
github.com/snapcore/snapd  v0.0.0-20240528091028-dc3b51bb4c9e  2.57.6    go-module  GHSA-cjqf-877p-7m3f  High
github.com/snapcore/snapd  v0.0.0-20240528091028-dc3b51bb4c9e  2.62      go-module  GHSA-69p6-gp5x-j269  Medium
github.com/snapcore/snapd  v0.0.0-20240528091028-dc3b51bb4c9e  2.62      go-module  GHSA-64jh-cjwc-w8q6  Medium
github.com/snapcore/snapd  v0.0.0-20240528091028-dc3b51bb4c9e  2.62      go-module  GHSA-4mh8-9689-38vr  Medium
golang.org/x/crypto        v0.0.0-20220829220503-c86fa9a7ed90  0.17.0    go-module  GHSA-45x7-px36-x8w8  Medium
golang.org/x/net           v0.9.0                              0.17.0    go-module  GHSA-4374-p667-p6c8  High
golang.org/x/net           v0.9.0                              0.17.0    go-module  GHSA-qppj-fm5r-hxr3  Medium
golang.org/x/net           v0.9.0                              0.23.0    go-module  GHSA-4v7x-pqxf-cx7m  Medium
golang.org/x/net           v0.9.0                              0.13.0    go-module  GHSA-2wrh-6pvc-2jm9  Medium

Strict

I rebuilt the grype snap with strict confinement as ‘strict-grype’ (but didn’t publish, only installed locally) and ran some examples. Unsurprisingly these fail for filesystem permission reasons.

This example should be lengthy, as with the first example above.

$ snap run strict-grype dir:/snap/core22/current/
 ✔ Vulnerability DB [updated]
 ✔ Indexed file system /snap/core22/1439
 ✔ Cataloged contents 0bb364a1df4912b90f320959ddac175a0ea326d02296212a31c798938ae03abf
   ├── ✔ Packages                        [0 packages]
   └── ✔ Executables                     [0 executables]
 ✔ Scanned for vulnerabilities     [0 vulnerability matches]
   ├── by severity: 0 critical, 0 high, 0 medium, 0 low, 0 negligible
   └── by status:   0 fixed, 0 not-fixed, 0 ignored
[0000]  WARN no explicit name and version provided for directory source, deriving artifact ID from the given path (which is not ideal)
[0000]  WARN unable to get system mounts error=open /proc/thread-self/mountinfo: permission denied
[0000]  WARN unable to access path="/snap/core22/1439": open /snap/core22/1439: permission denied
No vulnerabilities found
$ snap run strict-grype dir:/srv/repo/snapcore/snapd
 ✔ Vulnerability DB [no update available]
failed to catalog: an error occurred attempting to resolve '/srv/repo/snapcore/snapd': additionally, the following providers failed with file does not exist: oci-dir, oci-dir, local-directory

On the flipside - some features do work fine of course while strictly confined. Grabbing an oci container from a popular registry to scan works.

$ snap run strict-grype ubuntu:latest
 ✔ Vulnerability DB [no update available]
 ✔ Parsed image sha256:35a88802559dd2077e584394471ddaa1a2c5bfd16893b829ea57619301eb3908
 ✔ Cataloged contents c920ba4cfca05503764b785c16b76d43c83a6df8d1ab107e7e6610000d94315c
   ├── ✔ Packages                        [91 packages]
   ├── ✔ File digests                    [2,038 files]
   ├── ✔ File metadata                   [2,038 locations]
   └── ✔ Executables                     [722 executables]
 ✔ Scanned for vulnerabilities     [11 vulnerability matches]
   ├── by severity: 0 critical, 0 high, 2 medium, 7 low, 2 negligible
   └── by status:   4 fixed, 7 not-fixed, 0 ignored
NAME          INSTALLED            FIXED-IN           TYPE  VULNERABILITY   SEVERITY
coreutils     9.4-3ubuntu6                            deb   CVE-2016-2781   Low
gpgv          2.4.4-2ubuntu17                         deb   CVE-2022-3219   Low
libc-bin      2.39-0ubuntu8.2                         deb   CVE-2016-20013  Negligible
libc6         2.39-0ubuntu8.2                         deb   CVE-2016-20013  Negligible
libgcrypt20   1.10.3-2build1                          deb   CVE-2024-2236   Medium
liblzma5      5.6.1+really5.4.5-1                     deb   CVE-2020-22916  Medium
libpcre2-8-0  10.42-4ubuntu2                          deb   CVE-2022-41409  Low
libssl3t64    3.0.13-0ubuntu3.1    3.0.13-0ubuntu3.2  deb   CVE-2024-5535   Low
libssl3t64    3.0.13-0ubuntu3.1    3.0.13-0ubuntu3.2  deb   CVE-2024-4741   Low
libssl3t64    3.0.13-0ubuntu3.1    3.0.13-0ubuntu3.2  deb   CVE-2024-4603   Low
libssl3t64    3.0.13-0ubuntu3.1    3.0.13-0ubuntu3.2  deb   CVE-2024-2511   Low

Hope that’s everything you need.

Happy to answer any questions.

:pray:

As per the previous request for classic for syft, grype also fits the same requirement for classic confinement. As @popey was previously vetted in Request classic confinement for syft - #8 by 0xnishit as a trusted contributor to the upstream syft repository via his popey (Alan Pope) · GitHub account, and I can see he is also a contributor via this same account to grype - Commits · anchore/grype · GitHub - we can conclude he is also a trusted member of the grype upstream (not to mention he is employed by the maintainer of grype, Anchore).

As such, the requirements for classic confinement are understood and I have vetted the publisher. This is now live.

1 Like