Switch Seccomp back on

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

[dangowrt]

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]

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]

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