Getting away from libseccomp

[utam0k]

We will start looking into the possibility of implementing our own seccomp. libseccomp dependency issues have erupted in various places.
It would not be necessary to actually support that many architectures. However, we only need to know the number of the system call for each archs.

TODO:

• SeccompRule
  • In this step, we only add the unit test for SeccompRule. It means we don't integrate it into main.rs
• Seccomp structure that bundles SeccompRule.
  • The main.rs is completed here.
• Support Arm64
• Integrate to libcontainer

[utam0k]

I'll give it a try to implement PoC

[jprendes]

That's great!
Particularly, as libseccomp is LGPL licensed.
I know runc adds the libseecomp tarbal to their release due to static builds (see here), something we don't currently do.

[YJDoc2]

This would be great! Let me know if I can help in any way 💜

[YJDoc2]

Hey, we should also take a look at https://github.com/rust-vmm/seccompiler

[utam0k]

Hey, we should also take a look at https://github.com/rust-vmm/seccompiler

Thanks for sharing. I have already checked it but it doesn't support seccomp notify.

[sat0ken]

I will try this issue, OK?

[YJDoc2]

Hey @sat0ken , utam0k is already working on this. If you have access to WSL, can I suggest trying #2484 , as currently we don't have someone with access to WSL, and it would be great help!

[sat0ken]

@YJDoc2 Sure！I will check #2484, and try it on WSL.

[utam0k]

@sat0ken As a next step, how about testing with moby's default.json?
https://github.com/moby/moby/blob/master/profiles/seccomp/default.json