1. 21 Jan, 2017 1 commit
  2. 29 Jul, 2016 1 commit
    • intrigeri's avatar
      Test suite: only query type A when exercising DNS lookups. · 08439689
      intrigeri authored
      I've seen this failure:
        When I do a TCP DNS lookup of "torproject.org"
        Failed to resolve torproject.org:
        Using domain server:
        torproject.org has address
        torproject.org has address
        torproject.org has address
        torproject.org has address
        torproject.org has address
        torproject.org has IPv6 address 2620:0:6b0:b:1a1a:0:26e5:4810
        torproject.org has IPv6 address 2001:41b8:202:deb:213:21ff:fe20:1426
        torproject.org has IPv6 address 2a01:4f8:172:1b46:0:abba:5:1
        torproject.org has IPv6 address 2001:858:2:2:aabb:0:563b:1e28
        Host torproject.org not found: 2(SERVFAIL)
        is not true. (Test::Unit::AssertionFailedError)
        ./features/step_definitions/firewall_leaks.rb:21:in `/^I do a TCP DNS lookup of "(.*?)"$/'
        features/tor_enforcement.feature:32:in `When I do a TCP DNS lookup of "torproject.org"'
      i.e. A and AAAA were successfully queried, but the MX query failed.
      Here, we don't care about the query type whatsoever: once *one* DNS
      query is out, what we are really interested in is the next step,
      i.e. "the firewall leak detector has detected leaks".
      So, let's avoid such failures by sending a simpler DNS query.
  3. 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
      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
  4. 30 Nov, 2015 1 commit
  5. 20 Nov, 2015 1 commit
    • intrigeri's avatar
      Test suite: run ping as root. · 59a55080
      intrigeri authored
      On Jessie, setcap is used by default instead of setuid root for /bin/ping,
      but aufs does not support file capabilities:
        $ /sbin/getcap /bin/ping
        Failed to get capabilities of file `/bin/ping' (Operation not supported)
        $ /sbin/getcap /lib/live/mount/rootfs/filesystem.squashfs/bin/ping
        /lib/live/mount/rootfs/filesystem.squashfs/bin/ping = cap_net_raw+ep
      We could of course make /bin/ping setuid root back, just as it has
      always been, but with our firewall it'll only allow pinging the LAN; for
      now, I'm deciding that the limited usefulness is not worth the security
      implications (even though we confine ping with AppArmor), and ping will
      remain root only for now. We'll see how much sensible complains we get
      during the 2.0 beta and RC phases.
  6. 07 Sep, 2015 1 commit
  7. 08 Jul, 2015 1 commit
    • intrigeri's avatar
      Test suite: run ping as root. · 8be56369
      intrigeri authored
      For some reason, on Jessie, running ping as a regular users results in "ping:
      icmp open socket: Operation not permitted", with exit code == 2. But as root, it
      "works" and the firewall blocks the packets. This is rather an improvement than
      a problem (stuff is blocked earlier, which is cheaper), so let's just deal with
      it in the test suite only, by running ping as root: the main purpose here is to
      test the firewall.
      This change also affects the netcat command used to open TCP and UDP
      connections, for code simplicity's sake. Here again, the goal is to test
      the firewall.
  8. 15 May, 2015 1 commit
  9. 10 Apr, 2015 2 commits
  10. 23 Feb, 2015 1 commit
  11. 09 Feb, 2015 2 commits
  12. 03 Feb, 2015 1 commit
    • Tails developers's avatar
      Move misc code into FirewallLeakCheck. · 9704789f
      Tails developers authored
      This is where it belongs, and soon we'll need to use the same code in
      a scenario hook, and calling a step in such a way makes me
      (FWIW, this is a remnant from the good ol' unmerged
      test/firewall-check-tag branch.)
  13. 19 Jan, 2015 2 commits
  14. 02 Apr, 2013 1 commit