[tor-bugs] #9168 [Tor]: GSOC seccomp stage 1

[Tor Bug Tracker & Wiki]

#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