snap-{confine,seccomp}: make @unrestricted fully unrestricted #4054
Conversation
For @unrestricted we did load a "allow-all" bpf program so far. However in LP: 1724697 the LXD team asks for fully unrestricted mode (i.e. no filter at all) because they need to put their own filter in place and they don't stack apparently. The only downside/risk with this branch is that if snapd and snap-confine get out of sync things will get messy as an old snap-confine will try to load an invalid bpf program (the program that reads "@unrestricted").
Codecov Report
@@ Coverage Diff @@
## master #4054 +/- ##
==========================================
- Coverage 75.75% 75.75% -0.01%
==========================================
Files 435 435
Lines 37442 37441 -1
==========================================
- Hits 28366 28365 -1
Misses 7094 7094
Partials 1982 1982
Continue to review full report at Codecov.
|
There was a problem hiding this comment.
Thanks for this PR!
The memcmp() is technically fine but it means that @unrestricted<GARBAGE> is allowed. I also don't like text files that have a missing newline, which we do in this PR. I'd prefer we be a little more tidy. Eg, test for "@unrestricted\n" and test the size of the file. Another option is simply to use an empty file.
|
@jdstrand I'd like to avoid an empty file as any glitch that truncates the seccomp profile could turn it into accidental unconfined profile. I think the string is a good and explicit expression of that. |
|
approach looks good to me |
For @unrestricted we did load a "allow-all" bpf program so far.
However in LP: 1724697 the LXD team asks for fully unrestricted
mode (i.e. no filter at all) because they need to put their own
filter in place and they don't stack apparently.
The only downside/risk with this branch is that if snapd and
snap-confine get out of sync things will get messy as an old
snap-confine will try to load an invalid bpf program
(the program that reads "@unrestricted").