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 _______________________________________________ tor-dev mailing list [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
