| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
continuation of 79d832c37
|
| |
|
|
|
|
|
| |
ref. https://todo.sr.ht/~bptato/chawan/23
TODO: I'm not quite sure *why* it's getting called. curls operate in
mysterious ways.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
* fix matching on unstripped whitespace: caught after upgrading to
upstream dash & chaseccomp wouldn't compile
* add defines to ensure that we computed the filter length correctly
* inline cut_label
* EPERM on sigaction, sigprocmask, gettid, and kill on tgkill (so a
crash doesn't trigger sandbox violations)
* move SIGSYS handler to C and add one for the network
The last change removes the stack trace from SIGSYS, but gives us the
syscall number which is probably more useful. (Indeed, we don't even
have a stack trace in release builds.)
|
|
|
This drops libseccomp as a dependency.
Also, move the capsicum/pledge definitions from bindings to sandbox.nim
because they are only used there.
Interestingly, after integrating chaseccomp I found that the
stbi process would mysteriously crash by a getrandom(2) syscall.
Closer investigation revealed it is only called on the initialization
of glibc's malloc; presumably it had never surfaced before because
libseccomp would always allocate before entering the sandbox.
So I've added getrandom to our filter as well.
|