Add hashcash PoW challenge

[disconnect3d]

It would be nice to have a --hashcash option for -Ml, so that nsjail would generate a PoW challenge with configured difficulty.

That would make it easier for hosting CTF challenges that needs some anti-ddos protection.

On the other hand, I am not sure if that's something that should be a core nsjail functionality, so maybe this should be realized as some kind of --exec-wrapper flag or just by the jailed program.

[robertswiecki]

@sroettger wdyt?

[robertswiecki]

Example:

nc -v kctf.vrp.ctfcompetition.com 1

[sroettger]

The --exec-wrapper proposal sounds nice. In kctf we just ship a shell script that does the PoW and then runs the real challenge: https://github.com/google/kctf/blob/alpha/base/nsjail-docker/files/proof_of_work/maybe_pow.sh

The downside of this is that the pow script needs to live in the challenge chroot which exposes an unnecessary implementation detail.

[sroettger]

@sirdarckcat fyi

[robertswiecki]

Wouldn't it make sense to add some pool of preexec modules (configurable) instead? Adding --exec-wrapper doesn't seem to be conceptually better than just doing /bin/sh -c 'pow.py && challenge' and mapping both into the namespace.

If this is something useful for many, then maybe something like

--preexec_module pow:param1=1:param2=2

We could add a simple login/password thing, and pow, and maybe something else. I'll defer to your all judgement, so just my 2c.

[sirdarckcat]

would the preexec_module run inside the jail or outside?

[vesim987]

Hi, about a month ago I've created simple PoC for --exec-wrapper(link) it is using execveat to execute the wrapper, so we can avoid leaking the wrapper to the jailed process. And also it can pass the executable file descriptor to the wrapper.

Depending on the mode, it is executing the wrapper with argv set to ["exec_wrapper", "--fd", fd] or ["exec_wrapper", "--file", path].

If that's fine I can create PR with that.

[robertswiecki]

I'm still a bit on the side of builtin modules, as --exec-wrapper will only exec something before intended app, and it doesn't help that much IMO users, since they can call the pow.py from their binary, or from the intermediate bash script.

honggfuzz --preexec module=pow:keysize=4096:timeout=10 ....params... -- /bin

or

honggfuzz --preexec module=login:user=user:timeout=10:password=<sha256> ....params... -- /bin

WDYT, if there will be no support for this idea, I'd be fine with --exec_wrapper.

[sroettger]

The --exec-wrapper is still something we would like to use for https://github.com/google/kctf. I.e. in kctf, we provide a proof-of-work as part of our infrastructure and the chroot is mostly controlled by the user. In the current world, we have to add files to the user's chroot (we create /.kctf/), need to make sure that python3 is installed in the chroot and that the proof-of-work works with the user's nsjail configuration. We could skip all of this, if we could simply run the proof-of-work before nsjail sets up the namespaces etc. It would also have the nice side effect that the pow runs before all these resources are created (don't know if namespace creation still has weird bottlenecks).

[sroettger]

I implemented this as a poc (needs some polishing): https://github.com/sroettger/nsjail/commit/8f4c3a985d5eee5521da12343b8f1dd219e44192

Wdyt?

[sroettger]

We're going to use socat + nsjail in mode "once" now for our usecase: https://github.com/google/kctf/pull/168