1. 11 May, 2016 1 commit
  2. 20 Apr, 2016 1 commit
    • anonym's avatar
      Completely rewrite the firewall leak detector. · c2a2465c
      anonym authored
      The old design was very inflexible, which over time lead to the
      implementation growing messy as different checks were added. The
      issue was that it had to hard-code the particular checks we
      wanted, and did not allow the user to formulate an expression for
      which packets are considered leaks or not. So, let's instead
      provide an assertion-like function to which the user passes a
      block describing how we want all our packets to look.
      
      Furthermore, now all firewall leak tests should be ok with the
      simulated Tor network provided by Chutney. Since all Tor nodes
      (incl. bridges) run from the same host (and IP address) we also
      include the server port when verifying that no unexpected hosts were
      contacted.
      
      Note that in some cases we've lost a bit of information and
      precision, e.g. among the anti-tests we no longer exactly match
      the protocol that was leaked, but that wasn't very valuable to
      begin with, and instead we test *exactly* the code that these are
      anti tests for -- a true anti test, indeed!
      
      Also, the 'no traffic has flowed to the LAN' (now renamed) had a
      serious bug which was fixed in passing -- the `@lan_host`
      variable was not set, so it is `nil`, which could never be among
      the IPv4 TCP leaks, so that step always succeeded! :S
      c2a2465c
  3. 15 Apr, 2016 1 commit
  4. 08 Jan, 2016 2 commits
  5. 07 Dec, 2015 2 commits
  6. 03 Dec, 2015 1 commit
  7. 15 Oct, 2015 2 commits
  8. 06 Oct, 2015 1 commit
    • anonym's avatar
      Improve names of generated snapshot restoring steps. · 83bde0f9
      anonym authored
      Essentially I did:
      
          sed -i 's/Tails has booted/I have started Tails/' -- \
              features/*.feature features/step_definitions/snapshots.rb
      
      (although there was a false positive that I had to restore)
      83bde0f9
  9. 02 Oct, 2015 1 commit
  10. 14 Aug, 2015 1 commit
  11. 13 Aug, 2015 1 commit
  12. 08 Aug, 2015 2 commits
    • intrigeri's avatar
      Test suite: bump timeout. · ef20dc4e
      intrigeri authored
      ef20dc4e
    • anonym's avatar
      Rework how we test AppArmor denials. · 5cb5daf4
      anonym authored
      The basic idea is to first run a "I start monitoring the AppArmor log"
      step, which records the current time, and that any "AppArmor has
      denied" step run for the same profile later will only look at entries
      from that time and on. The wordings on the steps now make the
      scenarios a bit clearer, and we also don't have to clear syslog any
      more as an ugly workaround.
      
      Furthermore, this will bring us close to a clean solution of #9924,
      which will require us to run a sysctl command *before* anything that
      could generate the AppArmor log entries we're interested in. The "I
      monitor" step is a perfect candidate for that, wereas we before would
      need yet another step.
      5cb5daf4
  13. 05 Aug, 2015 6 commits
  14. 04 Aug, 2015 1 commit
  15. 11 Jul, 2015 1 commit
  16. 02 Jul, 2015 1 commit
  17. 29 Jun, 2015 1 commit
    • anonym's avatar
      Directly verify apparmor blocking of the Tor Browser. · 36cb0492
      anonym authored
      ... by looking in the audit log. This way we actually know that
      apparmor denied the operation, and so we don't get false positives of
      some classes of errors (e.g. the file simply has wrong permission or
      similar).
      
      Since we migrated to a browser based on Firefox esr38 we no longer get
      any graphical feedback for the apparmor blocking, which is the actual
      reason for implementing this.
      36cb0492
  18. 03 Jun, 2015 4 commits
  19. 28 May, 2015 2 commits
  20. 27 May, 2015 1 commit
  21. 15 May, 2015 2 commits
  22. 14 May, 2015 1 commit
  23. 05 May, 2015 1 commit
  24. 10 Apr, 2015 2 commits
    • anonym's avatar
      Actually run a web server on the LAN. · 709c9c75
      anonym authored
      It shouldn't be needed for the Tor Browser test since we check the
      network traffic, but we'll need it when testing the Unsafe Browser, so
      why not?
      709c9c75
    • anonym's avatar
      Test that the Tor Browser cannot access LAN resources. · 1d27515e
      anonym authored
      Since no HTTP server is listening on the LAN resource the Tor Browser
      would show the same "Unable to connect" error message even if the
      request wasn't blocked. We should be fine, though, since we check the
      captured traffic. The picture is more of a signal saying that "now the
      network traffic would have been generated *if* the request isn't
      blocked" which we use to know when to check the network capture.
      1d27515e
  25. 18 Feb, 2015 1 commit