RFE: distinguish unknown syscalls

[srd424]

Triggered by a discussion (in June & Aug) on systemd-devel ..

systemd-nspawn chooses to return EPERM for non-whitelisted syscalls. However, this causes problems in cases like openat2, where libc checks for ENOSYS and falls back to a different implementation.

It seems to me a 'mostly right' solution could be to check if the syscall number falls within the range of defined syscalls that existed at the time seccomp was built. I'm sure there are corner cases (I know some archs do weird things), but if the tools that parse syscalls.csv etc could generate a simple #define for the max known syscall number that might be useful?

[pcmoore]

Hi @srd424. I want to make sure I understand what you are asking for in this issue ... it sounds to me that you would basically like to know if libseccomp "knows" about a given syscall, regardless of if that particular syscall is implemented on that arch/ABI, yes?

If so, I believe you should be able to use seccomp_syscall_resolve_name(...) to get the information you want. If the return value is __NR_SCMP_ERROR then the syscall is unknown to libseccomp, if it is positive then the syscall exists in the native arch/ABI, and if it is negative then the syscall does not exist on the native arch/ABI. Does that work for you?

[srd424]

That might make the filters .. long-winded!

What I was hoping to do is to to have a filter rule compare the syscall number to the highest known, and if greater, return ENOSYS, otherwise return EPERM (Assuming that whitelisted syscalls have been handled by an earlier rule.)

However looking at the details for seccomp_rule_add, I'm not sure that is going to work .. the syscall number is treated specially. A raw bpf filter could presumably be constructed to do this, but that's going to mean some more invasive changes to libseccomp - probably above my pay grade!

[srd424]

It might or might not be reasonable functionality to add to libseccomp as I guess the original problem may occur for multiple users of the library. It looks like it would (just?) be a question of generating a slightly more sophisticated default action..

[pcmoore]

That might make the filters .. long-winded!

I'm not quite sure what you mean here ... ? The call to seccomp_syscall_resolve_name(...) doesn't actually affect the filter, it just queries the internal libseccomp syscall db to do the syscall resolution. You can call it once, one thousand times, or never and your filter will be exactly the same :)

What I was hoping to do is to to have a filter rule compare the syscall number to the highest known, and if greater, return ENOSYS, otherwise return EPERM (Assuming that whitelisted syscalls have been handled by an earlier rule.)

Okay, I think I'm beginning to understand what you are asking for now. You want the filter itself, not the application code, to take a certain action (return ENOSYS in the example above) if the syscall is unknow to libseccomp? Is that basically it, or am I missing something again?

[drakenclimber]

This comment in the second thread mentioned above made me smile 👍

I've tried to open a discussion about the ENOSYS handling in libseccomp at
#286, but I'm probably not
being very coherent..

After reading through the threads you mentioned, I think I'm on the same page.

If someone (libseccomp, nspawn, whoever) could return ENOSYS, then glibc will try to fallback from the newer syscall, e.g. openat2, to the older syscall, e.g. openat. Returning EPERM to glibc just makes glibc think that the call was not allowed, and glibc will give up. Is that a fair rewording of the initial comment in this issue?

I think the request is reasonable. I need to think some more if libseccomp can meet these needs, but I have no objections at this point. There are definitely opportunities to improve the end-user experience here.

Thanks for the RFE.

[srd424]

If someone (libseccomp, nspawn, whoever) could return ENOSYS, then glibc will try to fallback from the newer syscall, e.g. openat2, to the older syscall, e.g. openat. Returning EPERM to glibc just makes glibc think that the call was not allowed, and glibc will give up. Is that a fair rewording of the initial comment in this issue?

Yes, that sounds right. The opinion of the systemd folks is that EPERM is reasonable most of time for denylisted syscalls, presumably as it conveys "not allowed" to end user / admin. Hence the idea to distinguish between "new" and "old" syscalls and do ENOSYS for anything unrecognised. I assume we don't want to enumerate and test every single syscall in the BPF for performance reasons, so tracking a high water mark for the known syscall numbers per-arch seemed like a "best effort" way to go.

Would be interesting to know what docker, podman, lxc etc. do with their seccomp filtering, to see if they would benefit. In the meantime I've PR'd a patch for nspawn that would allow logging of seccomp events, that would make debugging a little easier.

[pcmoore]

I think the request is reasonable. I need to think some more if libseccomp can meet these needs, but I have no objections at this point. There are definitely opportunities to improve the end-user experience here.

Thanks for the RFE.

I agree with @drakenclimber, this request sounds reasonable, I think I just need some more time to think about possible solutions :)

At a pretty basic level, this is similar to RFE #11, and in the end that may be the easiest way to implement this in a way that isn't terrible for applications: an application can specify a maximum supported kernel API version, e.g. v5.8 (obviously tokenized), as well as a given action for anything beyond and then libseccomp handles the rest. Would that work for you guys @srd424?

[keszybz]

Hi, this was discussed also in systemd/systemd#16739.

an application can specify a maximum supported kernel API version, e.g. v5.8 (obviously tokenized), as well as a given action for anything beyond and then libseccomp handles the rest.

This would work great. In systemd/systemd-nspawn we'd want to return custom errnos for any explicitly allow-listed and deny-listed syscalls, EPERM for any others in the "supported kernel API version", and ENOSYS for any new ones.

I think the implementation wouldn't be too complicated. For example for amd64, "known" syscalls can be expressed as n <= 181 || 186 <= n <= 235 || 237 <= n <= 334 || 424 <= n <= 439. And such expressions can be easily generated programatically from the syscall tables.

[topimiettinen]

#94 could be related too.