[tor-dev] [GSOC] Status report - Tor capabilities

[Jacob Appelbaum]

Cristian-Matei Toader:
> Hello tor-dev,
> 
> Here goes the status report for the past 2 weeks
> - I have been preparing the code for the first step of the project to
> be merged in the Tor master branch, which represented a number of
> changes required by nickm; the full process can be seen here [1], the
> branch was squashed and should be merged one of these days.
> 

Sounds great! I'm happy to review this branch as well, if you'd like?

> - Step 2:
>   - current progress
>   - has changed a bit, and now requires to create a sandbox as 'tight'
> as possible around the Tor syscalls;
>   - this is achieved my filtering not only syscalls but also syscall
> parameters, current efforts on my part can be found here [2] in branch
> "gsoc-cap-stage2";

Would you like review on this branch as well?

>   - the current problem with this stage is filtering string parameters
> for syscalls which can be done using immutable strings using protected
> memory regions;
>   - unfortunately some syscalls are out of reach being part of
> libraries and therefore their parameters cannot be controlled (the
> pointer used in the seccomp filter cannot be reference in the syscall)
> which will need to be solved (any suggestions are appreciated).
> 

Are the parameters non-deterministic? If the library code is in the same
process as the sandboxed Tor, what is the problem exactly?

> - I have implemented ioerror's suggestion about policy files but is
> not pushed to git mainly because after talking to nickm we concluded
> that the implementation effort is not justified especially now when
> filter configurations are constantly changing which would require also
> changing how policy files are parsed, having mostly the same end
> result; furthermore some of the string filter parameters may be
> generated on runtime, which may be inconsistent with the solution, but
> I will keep this in mind towards the finishing stage of the
> development process, especially since it offers an elegant way of
> configuring and testing different filters.

This seems odd - perhaps I should restate my suggestion - my suggestion
is to make a master file that contains the policy definitions. It can be
used as a template for output into different formats - so for example,
one could build C source code files or expand macros for use in source
code, while also creating the simple minijail policies as we have in
tlsdate. I could sketch out something that does this - if we had a
standard way of outputting for the various uses, eg: minijail, seccomp2
configuration in C, etc. What else, I wonder?

In any case, if you have code or changes, please do put them in the
repo, even if they're not finished or perfect.

> 
> As a small side-note I will mostly be traveling the majority of next
> week, so I may not be as reachable as before.
> 

Have a great summer!

> Looking forward to some feedback, if you happen to have any!

I'll look at the code on github this coming week.

All the best,
Jacob