BUG: cannot add blacklist items to a whitelist

[justincormack]

For docker we ship a default seccomp profile that is a whitelist using libseccomp-golang see https://github.com/docker/docker/tree/master/profiles/seccomp

However it seems to be impossible to have a default action of ERRNO and then add an ERRNO rule to blacklist a particular pattern as we get a "requested action matches default action of filter" error message passed through from libseccomp.

We want to block some particular argument values of a particular syscall (see moby/moby#23893 ), so eg setsockopt(x, 0, 41, x) and setsockopt(x, 0, 96, x) and setsockopt(x, 41, 41, x) should be denied, while allowing any other values, but although this can easily be written with a socket filter directly, it does not seem to be possible to write with libseccomp.

I was wondering if perhaps it could accept rules with the same action as the default and construct the appropriate bpf.

This is also mentioned in this issue comment, although there is workaround in that case #27 (comment)

[pcmoore]

We don't want to allow rules with the same action as the default action (that doesn't make any sense), but we should take into account the errno value when making this decision. For example, we should allow a rule with ERRNO(y) when the default rule is ERRNO(x), but block the addition of a rule with ERRNO(x). Does that make sense?

We should also apply the same change to the TRACE(x) handling.

[justincormack]

Hi, no that is not what my issue is, that is a different issue. My issue is that I cannot express the rules I want at all, I was just suggesting that perhaps one workaround would be to accept those rules and interpret them as a way of making the required bpf program, as the current format is not expressive enough for me to write the rules I want.

[pcmoore]

Okay, I guess I'm a bit confused by this section of your original problem report:

However it seems to be impossible to have a default action of ERRNO and then add an ERRNO rule to blacklist a particular pattern as we get a "requested action matches default action of filter" error message passed through from libseccomp.

Can you help clarify this for me?

[justincormack]

Well I just thought one way of specifying a blacklist item with a whitelist might be to try to return the same return value as the default, ie errno, but obviously that doesnt work. What I want is:

default errno
if match1 then errno
if match2 then errno
otherwise allow

The actual bpf program wouldnt look quite like this, but the libseccomp format doesnt express jumps...

[pcmoore]

Okay, I think I understand what you are trying to do now and you can't do that, although to be honest you really shouldn't be doing that as there is a simpler approach. Taking your example above:

default errno
if match1 then errno
if match2 then errno
otherwise allow

NOTE: the "otherwise" is slightly ambiguous as it is unclear if it belongs to the second if-condition or the filter as a whole, I'm assuming the latter.

You define a default action of "errno", but in reality the default action is "allow" as your filter only triggers "errno" if "match1" or "match2" are true. I would suggest the following as functionally equivalent and libseccomp-legal alternative:

default allow
if match1 then errno
if match2 then errno

Does that make sense? Am I misunderstanding what you are trying to do?

[pcmoore]

Actually, it doesn't matter if the "otherwise" is for the second if-condition or the filter as a whole, the suggested filter should work just fine.

[justincormack]

We can't have a default of allow as we are using a whitelist.

[pcmoore]

The example you provided isn't a whitelist.

[justincormack]

The full profile is a whitelist, but I want to effectively blacklist a few specific patterns. If I was writing a filter program by hand I could do that with some conditions and jumps, but I cannot express that with libseccomp as far as I can see.

[pcmoore]

I'm still somewhat at a loss. If you have a whitelist and you want to exclude specific patterns you leave them out of the rules you explicitly add, it's that simple.

Are you basically looking for a runtime assert(3) API for the libseccomp filter?

Also, don't forget that you can install multiple filters for any given process; each filter will be executed with the most restrictive action being the winner. For example, if you had a whitelist where you wanted to allow "match2" and "match4" but you wanted to explicitly disallow "match1" and "match3" you could create two filters like the following:

# whitelist
default errno
if match2 then allow
if match4 then allow

# blacklist
default allow
if match1 then errno
if match3 then errno

Using the two filters above, you still have an effective blacklist as the most restrictive default is the "errno" from the whitelist with "match2" and "match4" being allowed as they are only mentioned in the whitelist and "match1" and "match3" being denied with "errno" as they are explicitly mentioned in the blacklist. My guess is this best fits what you are trying to do.

[justincormack]

I cant "leave out" the rules from a rule that otherwise accepts every value, when they are of the form register1=a, register2=b and there are several of them. I could have stacked profiles, but that adds a lot of complexity.

I am trying to drop the values of setsockopt that cause an issue for a CVE, see moby/moby#23893

[pcmoore]

I'm not sure what you mean by "profiles", but the way to do what I think you are asking is with the two installed filters as described above.

[justincormack]

yes, sorry, profiles=filters.

It is perfectly possible to do this natively with bpf with a single filter though, because it is fine to return with any return value anywhere in the filter. I know libseccomp is a simplification, but I don't see that it would be impossible to do the right code generation for this type of use case. Having two stacked filters makes our configuration much more complicated.

[pcmoore]

Yes, I'm well versed on what is possible with raw BPF, I've spent plenty of time looking at it the past few years. As you stated, providing all the functionality of raw BPF is not a goal of libseccomp (that would be silly); libseccomp is designed to make it easier for developers to use the seccomp mode 2 functionality by providing an ABI agnostic programmatic interface that doesn't suck too badly.

What you are asking for is currently handled via two filters in libseccomp, that is the recommended solution. We will likely make the library more expressive in the future, but the functionality you are asking for isn't likely to be introduced soon enough to satisfy your immediate need. As I stated before, I'm not too familiar with the Docker/libseccomp integration, but it seems to me that it tying a syscall filtering profile to a single libseccomp filter is not the best solution, especially given this idea of blocking specific syscall invocations in order to block CVEs/exploits. However, you know Docker/libseccomp better than I do.

Regardless, I don't think there is much we can do on the libseccomp end of things right now, beyond what I've mentioned above. I'll leave this issue open a bit longer in case you have something you would like to add.

[justincormack]

It is not an immediate need, we don't really need that PR for other reasons. But that type of thing may well come up again in future. Multiple filters is possible we have an issue moby/moby#22109 but adds a large amount of complexity for configuration that we want to avoid if at all possible. I would rather work on improving expressivity myself, but if that is not in the roadmap that is fine.

[pcmoore]

@justincormack Patches are always welcome :)