[tor-bugs] #9168 [Tor]: GSOC seccomp stage 1
Tor Bug Tracker & Wiki
blackhole at torproject.org
Thu Jul 4 15:14:59 UTC 2013
#9168: GSOC seccomp stage 1
--------------------------------------------+-------------------------------
Reporter: ctoader | Owner: nickm
Type: enhancement | Status: needs_review
Priority: normal | Milestone: Tor: 0.2.5.x-final
Component: Tor | Version:
Keywords: tor-relay gsoc seccomp sandbox | Parent:
Points: | Actualpoints:
--------------------------------------------+-------------------------------
Changes (by ctoader):
* status: needs_revision => needs_review
Comment:
Replying to [comment:6 nickm]:
> Follow-up review:
> * log_err() won't work any better from a signal handler than
fprintf(). It calls snprintf, which isn't in the signal-safe functions
list. Also, exit() isn't on the signal-safe functions list, either,
although _exit() is. If you have a look at "man sigaction" or "man 7
signal", it should list the functions which can be safely called.
I am now using only write and snprintf; snprintf is not part of the
signal-safe functions list but otherwise I didn't know how to add the
syscall number that caused the SIGSYS. This works fine on my PC. If you
want me to, I can just leave a write with a static message, or maybe you
have another suggestion.
> * Based on that, I wonder if there shouldn't be configurable levels of
sandboxing configurable, where one of them records the forbidden system
calls and continues, and one of them just aborts. Let's talk about the
right interface for that.
Ok so I left a symbol definition called _DEBUGGING_CLOSE, but you
probably had something more complex in mind but I couldn't reach you
today; right now I would recommend to always close, mainly because
whenever a syscall fails the program doesn't recover; if it happens in the
periodic callback functions it ends up spamming error messages.
> * Is the socketcall() thing still necessary now that we switched to
add from add_exact?
Unfortunately yes, I will keep looking into this.. I'll add the change
in the next version when I'll make the filter more restrictive.. Or if
there's no rush I'll keep looking into this these days.
>
> Other notes:
> * I still need to write the autoconf/automake magic here.
> * There should be documentation for the Sandbox option in
doc/tor.1.txt
I have written it.
> * Probably we should squash before merging. (The branch is 3184 lines
long, but the diff is only 339 lines long)
>
Also added mlockall to the syscall list, but a standard run with no
command line parameters works just fine without it.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/9168#comment:9>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
More information about the tor-bugs
mailing list