Request classic confinement for syft

Hi all.

Sorry, this is long; I wanted to make sure I provided all the necessary data so we can minimize any back and forth. :pray: :kangaroo:

Metadata

Syft

I’m requesting classic confinement for the Syft snap. Syft is a well-established, open-source, command-line utility SBOM 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 will (shortly) include automation to pull the latest stable releases of Syft, and automate publication in the store. The latest version in the yaml is v1.9.0, which is current

Edit: This is now done.

Classic confinement

Syft’s primary purpose is to scan containers, images and arbitrary folders to generate a Software Bill of Materials (SBOM). We have no control or visibility over where Syft will be run and against what filesystems or Linux distributions our users use.

Syft also uses external binaries such as cosign to perform attestation.

Further, Syft can be requested to write the SBOM files to any arbitrary location on the filesystem for storage or forwarding as the developer or architect deems necessary.

Examples

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

(ignore the [0000] WARN lines)

$ snap run syft dir:/snap/core22/current/ 
 ✔ Indexed file system                                                                                                       /snap/core22/1380
 ✔ Cataloged contents                                                         0bb364a1df4912b90f320959ddac175a0ea326d02296212a31c798938ae03abf
   ├── ✔ Packages                        [38 packages]
   └── ✔ Executables                     [1,470 executables]
[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/1380/etc/polkit-1/localauthority": open /snap/core22/1380/etc/polkit-1/localauthority: permissi
[0000]  WARN unable to access path="/snap/core22/1380/etc/ssl/private": open /snap/core22/1380/etc/ssl/private: permission denied
[0000]  WARN unable to access path="/snap/core22/1380/root": open /snap/core22/1380/root: permission denied
[0000]  WARN unable to access path="/snap/core22/1380/var/cache/ldconfig": open /snap/core22/1380/var/cache/ldconfig: permission denied
[0000]  WARN unable to access path="/snap/core22/1380/var/cache/private": open /snap/core22/1380/var/cache/private: permission denied
[0000]  WARN unable to access path="/snap/core22/1380/var/lib/polkit-1": open /snap/core22/1380/var/lib/polkit-1: permission denied
[0000]  WARN unable to access path="/snap/core22/1380/var/lib/private": open /snap/core22/1380/var/lib/private: permission denied
[0000]  WARN unable to access path="/snap/core22/1380/var/lib/snapd/void": open /snap/core22/1380/var/lib/snapd/void: permission denied
[0000]  WARN unable to access path="/snap/core22/1380/etc/ssl/private": open /snap/core22/1380/etc/ssl/private: permission denied
NAME                 VERSION    TYPE
Babel                2.8.0      python
Jinja2               3.0.3      python
MarkupSafe           2.0.1      python
PyJWT                2.3.0      python
PyYAML               5.4.1      python
attrs                21.2.0     python
bash                 5.1.16     binary
blinker              1.4        python
certifi              2020.6.20  python
chardet              4.0.0      python
cloud-init           23.4.4     python
configobj            5.0.6      python
cryptography         3.4.8      python
dbus-python          1.2.18     python
idna                 3.3        python
importlib-metadata   4.6.4      python
jsonpatch            1.32       python
jsonpointer          2.0        python
jsonschema           3.2.0      python
more-itertools       8.10.0     python
netifaces            0.11.0     python
oauthlib             3.2.0      python
openssl              3.0.2      binary
probert              0.0.18     python
pyrsistent           0.18.1     python
pyserial             3.5        python
python               3.10.12    binary
pytz                 2022.1     python
pyudev               0.22.0     python
requests             2.25.1     python
requests-unixsocket  0.2.0      python
setuptools           59.6.0     python
six                  1.16.0     python
subiquity            0.0.5      python
urllib3              1.26.5     python
urwid                2.1.2      python
util-linux           2.37.2     binary
zipp                 1.0.0      python
$ snap run syft scan dir:/srv/repo/snapcore/snapd
 ✔ Indexed file system                                                                                                /srv/repo/snapcore/snapd
 ✔ Cataloged contents                                                         f654a6fdb7d9fcbd6e09dbbb4643a1440479b64d05a7a4a00c8836171a112531
   ├── ✔ Packages                        [75 packages]
   └── ✔ Executables                     [13 executables]
[0000]  WARN no explicit name and version provided for directory source, deriving artifact ID from the given path (which is not ideal)
NAME                                    VERSION                               TYPE
actions/cache                           v3                                    github-action  (+1 duplicate)
actions/cache/save                      v3                                    github-action  (+1 duplicate)
actions/checkout                        v2                                    github-action
actions/checkout                        v3                                    github-action  (+3 duplicates)
actions/checkout                        v4                                    github-action
actions/download-artifact               v3                                    github-action
actions/labeler                         v4                                    github-action  (+1 duplicate)
actions/setup-go                        v3                                    github-action
actions/upload-artifact                 v3                                    github-action
canonical/has-signed-canonical-cla      v1                                    github-action
codecov/codecov-action                  v3                                    github-action
get-woke/woke-action-reviewdog          v0                                    github-action
github.com/bmatcuk/doublestar/v4        v4.6.1                                go-module
github.com/canonical/go-efilib          v0.3.1-0.20220815143333-7e5151412e93  go-module
github.com/canonical/go-efilib          v0.4.0                                go-module
github.com/canonical/go-sp800.108-kdf   v0.0.0-20210314145419-a3359f2d21b9    go-module      (+1 duplicate)
github.com/canonical/go-sp800.90a-drbg  v0.0.0-20210314144037-6eeb1040d6c3    go-module      (+1 duplicate)
github.com/canonical/go-tpm2            v0.0.0-20210827151749-f80ff5afff61    go-module      (+1 duplicate)
github.com/canonical/tcglog-parser      v0.0.0-20210824131805-69fa1e9f0ad2    go-module      (+1 duplicate)
github.com/coreos/go-systemd            v0.0.0-20180511133405-39ca1b05acc7    go-module
github.com/godbus/dbus                  v0.0.0-20190726142602-4481cbc300e2    go-module      (+1 duplicate)
github.com/gorilla/mux                  v1.7.4-0.20190701202633-d83b6ffe499a  go-module
github.com/gvalkov/golang-evdev         v0.0.0-20191114124502-287e62b94bcb    go-module
github.com/jessevdk/go-flags            v1.5.1-0.20210607101731-3927b71304df  go-module
github.com/juju/ratelimit               v1.0.1                                go-module
github.com/kr/pretty                    v0.2.2-0.20200810074440-814ac30b4b18  go-module
github.com/kr/text                      v0.1.0                                go-module
github.com/mvo5/goconfigparser          v0.0.0-20200803085309-72e476556adb    go-module      (+1 duplicate)
github.com/mvo5/libseccomp-golang       v0.9.1-0.20180308152521-f4de83b52afb  go-module
github.com/seccomp/libseccomp-golang    v0.9.2-0.20220502024300-f57e1d55ea18  go-module
github.com/snapcore/go-gettext          v0.0.0-20191107141714-82bbea49e785    go-module      (+1 duplicate)
github.com/snapcore/maze.io-x-crypto    v0.0.0-20190131090603-9b94c9afe066    go-module
github.com/snapcore/secboot             v0.0.0-20240411101434-f3ad7c92552a    go-module      (+1 duplicate)
github.com/snapcore/snapd               v0.0.0-20240528091028-dc3b51bb4c9e    go-module
go.etcd.io/bbolt                        v1.3.9                                go-module
go.mozilla.org/pkcs7                    v0.0.0-20200128120323-432b2356ecb1    go-module      (+1 duplicate)
golang.org/x/crypto                     v0.0.0-20220829220503-c86fa9a7ed90    go-module      (+1 duplicate)
golang.org/x/net                        v0.9.0                                go-module      (+1 duplicate)
golang.org/x/sys                        v0.7.0                                go-module      (+1 duplicate)
golang.org/x/term                       v0.7.0                                go-module
golang.org/x/text                       v0.9.0                                go-module
golang.org/x/xerrors                    v0.0.0-20220609144429-65e65417b02f    go-module      (+1 duplicate)
golangci/golangci-lint-action           v3                                    github-action
gopkg.in/check.v1                       v1.0.0-20201130134442-10cb98267c6c    go-module
gopkg.in/macaroon.v1                    v1.0.0-20150121114231-ab3940c6c165    go-module
gopkg.in/retry.v1                       v1.0.3                                go-module      (+1 duplicate)
gopkg.in/tomb.v2                        v2.0.0-20161208151619-d5d1b5820637    go-module      (+1 duplicate)
gopkg.in/yaml.v2                        v2.4.0                                go-module      (+1 duplicate)
gopkg.in/yaml.v3                        v3.0.1                                go-module
maze.io/x/crypto                        v0.0.0-20190131090603-9b94c9afe066    go-module
snapcore/action-build                   v1                                    github-action
tj-actions/changed-files                v41.0.0                               github-action  (+1 duplicate)

Strict

I rebuilt the snap with strict confinement and ran some examples. Unsurprisingly these fail for filesystem permission reasons.

$ snap run strict-syft scan dir:/snap/core22/current/
 ✔ Indexed file system                                                                                                       /snap/core22/1380
 ✔ Cataloged contents                                                         0bb364a1df4912b90f320959ddac175a0ea326d02296212a31c798938ae03abf
   ├── ✔ Packages                        [0 packages]
   └── ✔ Executables                     [0 executables]
[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/1380": open /snap/core22/1380: permission denied
No packages discovered
$ snap run strict-syft scan dir:/srv/repo/snapcore/snapd
could not determine source: 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-syft scan alpine:latest
 ✔ Parsed image                                                        sha256:324bc02ae1231fd9255658c128086395d3fa0aedd5a41ab6b034fd649d1a9260
 ✔ Cataloged contents                                                         eddacbc7e24bf8799a4ed3cdcfa50d4b88a323695ad80f317b6629883b2c2a78
   ├── ✔ Packages                        [14 packages]
   ├── ✔ File digests                    [77 files]
   ├── ✔ File metadata                   [77 locations]
   └── ✔ Executables                     [17 executables]
NAME                    VERSION      TYPE
alpine-baselayout       3.6.5-r0     apk
alpine-baselayout-data  3.6.5-r0     apk
alpine-keys             2.4-r1       apk
apk-tools               2.14.4-r0    apk
busybox                 1.36.1-r29   apk
busybox-binsh           1.36.1-r29   apk
ca-certificates-bundle  20240705-r0  apk
libcrypto3              3.3.1-r3     apk
libssl3                 3.3.1-r3     apk
musl                    1.2.5-r0     apk
musl-utils              1.2.5-r0     apk
scanelf                 1.3.7-r2     apk
ssl_client              1.36.1-r29   apk
zlib                    1.3.1-r1     apk

Hope that’s everything you need.

Happy to answer any questions.

:pray:

Hey @popey thank you for the detailed request post. It seems like a legitimate case for classic. Can you please categorise this tool and let us know in which category it fits well from here

Hi @0xnishit

Sorry, I thought I covered that. As I explained, syft needs arbitrary file access.

None of the supported or unsupported ‘known categories’ cover what syft 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)’

Developers and enterprises use syft in various ways. Some will use it to scan remote and local docker containers. Others will use it to scan tarballs of filesystem exports of containers. The big one that fails is scanning arbitrary filesystems or directories.

If you run syft and look at some examples, random files, and directories are well documented as standard use cases for the application. We cannot know in advance where people put their code repos, containers, etc.

  You can also explicitly specify the scheme to use:
    syft scan docker:yourrepo/yourimage:tag            explicitly use the Docker daemon
    syft scan podman:yourrepo/yourimage:tag            explicitly use the Podman daemon
    syft scan registry:yourrepo/yourimage:tag          pull image directly from a registry (no container runtime required)
    syft scan docker-archive:path/to/yourimage.tar     use a tarball from disk for archives created from "docker save"
    syft scan oci-archive:path/to/yourimage.tar        use a tarball from disk for OCI archives (from Skopeo or otherwise)
    syft scan oci-dir:path/to/yourimage                read directly from a path on disk for OCI layout directories (from Skopeo or otherwise)
    syft scan singularity:path/to/yourimage.sif        read directly from a Singularity Image Format (SIF) container on disk
    syft scan dir:path/to/yourproject                  read directly from a path on disk (any directory)
    syft scan file:path/to/yourproject/file            read directly from a path on disk (any single file)
1 Like

thank you for all the required information @popey. The requirement for classic is understood and this snap can be fitted in ‘access to files on the host outside the snap’s runtime (eg, /usr)’ category. I will start publisher vetting process

1 Like

@0xnishit FYI we previously vetted @popey in Classic confinement request for notepadnext snap so there is no need to do it again :wink:

As such, I have gone ahead and granted the classic confinement override for syft. This is now live.

Apologies @0xnishit and @popey, Nishit kindly reminded me that we have started vetting publishers on a per-snap basis (essentially to answer the question - is this publisher a trusted upstream for the snap) - as such, any previous vetting of a publisher is not really relevant. Since we have already granted classic confinement for the snap I don’t think it makes sense to revoke this (both since the revisions are now published AND since Alan works at Anchore (who publish Syft upstream)) as the vetting should be quite straight forward.

@0xnishit are you happy to continue with the vetting? Thanks

Good morning.

No problem at all. Happy to follow whatever the process is, of course. :+1:

After classic was granted, the latest build of syft was automatically released to the edge channel. I have closed that channel until we all have our ducks in a row.

Just ping if you need any further information from me. :pray:

The publisher is vetted. This is now live.

thanks @popey

1 Like