Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Switch Seccomp back on #9

Open
ghost opened this issue Jul 14, 2014 · 3 comments
Open

Switch Seccomp back on #9

ghost opened this issue Jul 14, 2014 · 3 comments
Labels

Comments

@ghost
Copy link

ghost commented Jul 14, 2014

Resolve cjdelisle/cjdns#529 first.
See 957d1d2.

@ghost ghost added bug and removed help wanted labels Jul 27, 2014
@ghost ghost self-assigned this Sep 27, 2014
@ghost ghost removed their assignment Nov 7, 2014
@dangowrt
Copy link
Contributor

From what I can see seccomp works great on the MIPS and ARM systems I tested. Is this issue still existing in current builds?

@wfleurant
Copy link
Member

good question. I usually enable seccomp, found this over the weekend (i think its IPTunnel related):

Wed Apr 15 01:32:57 2015 user.notice cjdns: Attempted banned syscall number [8] see doc/Seccomp.md for more information
  • note: I usually am testing against cjdns/crashey or hyperboria/next (~10 commits ahead of seattlemeshnet/meshbox)

Perhaps new cjdroute config time feature for seccomp is overruling this issue?

        // Seccomp is the most advanced sandboxing feature in cjdns, it uses
        // SECCOMP_BPF to filter the system calls which cjdns is able to make on a
        // linux system, strictly limiting it's access to the outside world
        // This will fail quietly on any non-linux system
        // Default: enabled
        { "seccomp": 1 },

@wfleurant
Copy link
Member

@lgierth Is this the related issue: hyperboria/bugs#6

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants