unknown syscall pidfd_open

[pkolano]

Can't compile default policy due to missing syscalls (likely because I'm on older 3.10 kernel). Don't know if this is a fatal message or just a warning, but the default policy doesn't even mention pidfd_open so it's strange that there is a message about it.

$ ./easyseccomp <contrib/default-policy.easyseccomp >default.bpf unknown syscall pidfd_open

[giuseppe]

it is probably coming from $syscall in KERNEL(5.3) => ERRNO(EPERM);

Could you tweak the kernel version there to use 3.10?

You may need to pull the latest changes I've pushed.

[pkolano]

Things look much better now. Everything builds properly without issue. I am still getting errors when building the default policy, however, even after changing the 5.3 to 3.10. Now, it is just ones in the policy that don't exist. For instance:

$ ../easyseccomp a.b unknown syscall clock_adjtime64

I assume it is immediately exiting after this since it doesn't complain about others that don't exist. It would be nice to have a mode where it just warns about non-existing system calls, but still builds what it can. That way, you could use the same policy for many kernel versions and it would ignore the ones that aren't applicable. I would also recommend adding "error:" or "warning:" text to the output so it is understood if the redirected output is actually valid or not. Thanks!

[giuseppe]

I assume it is immediately exiting after this since it doesn't complain about others that don't exist. It would be nice to have a mode where it just warns about non-existing system calls, but still builds what it can.

What do you suggest doing when the syscall is unknown?

If we just ignore the statement, I think it could be a risk with something like:

$syscall in (list of risky syscalls, @unknown_syscall) => ERRNO(EPERM);
=> ALLOW();

[pkolano]

I wasn't suggesting to ignore statements entirely, just to prune them of unsupported system calls. So for your example, your processor would vet each system call against what is supported on the system, which eventually would end up as:

$syscall in (list of risky syscalls) => ERRNO(EPERM); => ALLOW();

I don't know if there is any other mechanism available to determine those supported other than parsing the contents of /usr/include/asm/unistd_64.h

[giuseppe]

would it be better to run easyseccomp from a container using an updated OS image?

The bpf filter generated on a new system works well on older systems/kernels.

[pkolano]

ok, good to know, but doesn't fit my use case. I ended up just using libseccomp directly since I was having trouble loading any bpf file into the kernel whether produced by your tool or libseccomp export. Likely I was doing something wrong, but I kept getting errors on the prctl call while applying directly via libseccomp worked immediately without issue. Anyway, thanks for your assistance.

[giuseppe]

I wasn't aware that the bpf produced by easyseccomp would not work on old kernels.

Have you already found out what directive is causing the problem?

does something simple => ALLOW(); work?