mirror of
https://github.com/token2/snapd.git
synced 2026-03-13 11:15:47 -07:00
182b8ae699
* snap-{seccomp,confine}: rework seccomp denylist
When a denylist was introduced in PR#12849 we reached the limits
of the API of libseccomp and some things are now hard to reason
about [1]. This is mostly because what we try to do does not
match the libseccomp API very well and a slightly different
approach is probably more aligned with it's design (see also
this libseccomp issue [2] that is related to our issue).
So this commit changes the approach and instead of trying to use
a single filter the work is split into two filters:
1. explicit allow list
2. explicit deny list
and then load both filters into the kernel. The way the kernel
works is that it selects the most restrictive action.
So in the case of PR#12849:
```
~ioctl - TIOCSTI
~ioctl - TIOCLINUX
ioctl
```
For `ioctl(TIOCLINUX)` the first allow filter would pass `ioctl`
but the second deny filter would correctly deny the TIOCLINUX.
The file format of the `snap.snap.app.bin` changes to `.bin2`
and includes a proper header that would allow us to extend more
easily in the future.
The exiting tests for negative filtering got also updated so that
the deny/allow is tested via different errno numbers to ensure that
the expected filter denies the access.
The `snap-seccomp` spread test now also runs on all ubuntu releases.
This work will also allow us to remove the `global.bin` seccomp
filter in a followup PR.
[1] https://github.com/snapcore/snapd/pull/12849#discussion_r1206855700
[2] https://github.com/seccomp/libseccomp/issues/44
* snap-confine: tweak sc_seccomp_file_header struct (thanks Philip!)
* snap-confine: tweak struct init workaround in sc_apply_seccomp_profile_for_security_tag (thanks Philip)
* snap-seccomp: remove outdated comment about big endian
* snap-confine: rename sc_must_read_header_from_file->sc_must_read_and_validate_header_from_file
* snap-seccomp: rework exportBPF() to not require a temp file
Thanks to Valentin for the suggestion. Also reverts the change to
the `install-store-laaaarge` tests because there is no need for
space in /tmp anymore.
* tests: improve messae in security-seccomp deny test
* snap-confine: rename "struct stat buf" -> "struct stat stat_buf"
* snap-confine: check that filer size if multiple of sock_filter
Thanks to Valentin for the suggestion. Also adds a bunch of
C unit tests to check that the code works correctly. Sadly
C makes it hard to write this in a concise way so there is
a bit of repetition.
* snap-confine: extract must_read_and_validate_header_from_file_dies_with() helper
* snap-confine: workaround bug in gcc from 14.04
The gcc (4.8.4) in 14.04 will not compile the following code:
```
struct sc_seccomp_file_header hdr = {0};
```
and will error with:
```
snap-confine/seccomp-support.c: In function ‘sc_apply_seccomp_profile_for_security_tag’:
snap-confine/seccomp-support.c:246:9: error: missing braces around initializer [-Werror=missing-braces]
struct sc_seccomp_file_header hdr = {0};
^
snap-confine/seccomp-support.c:246:9: error: (near initialization for ‘hdr.header’) [-Werror=missing-braces]
```
to workaround this a pragma is added.
* snap-confine: check filters are not empty and keep read access to global.bin file
* tests: add details field to security-profiles and snap-seccomp spread tests
* snap-confine: move empty filter validation to sc_must_read_filter_from_file to avoid conflicts with classic snaps
* snap-{seccomp,confine}: add tests for missing seccomp profile and explicit deny has precedence to to explicit allow
* snap-confine: run make fmt
* cmd/snap-confine: make fmt again with indent 2.2.13+
Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com>
* snap-confine: Several code improvements
* snap-confine: Fix format
* snap-confine: Test fix and update deprecated SEEK_CUR
* snap-confine: Fix test
* snap-confine: Use inclusive language where possible
* snap-confine: Make woke happy until we can remove cmd/snap-seccomp-blacklist
---------
Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com>
Co-authored-by: Michael Vogt <mvo@ubuntu.com>
Co-authored-by: Maciej Borzecki <maciej.borzecki@canonical.com>