Bug #9704

iptables_parse is buggy for IPv6

Added by intrigeri 2015-07-08 02:12:10 . Updated 2016-06-30 08:12:22 .

Status:
Resolved
Priority:
High
Assignee:
Category:
Test suite
Target version:
Start date:
2015-07-08
Due date:
2016-01-15
% Done:

100%

Feature Branch:
Type of work:
Code
Blueprint:

Starter:
Affected tool:
Deliverable for:
268

Description

ip6tables doesn’t write anything in the opt column in our configuration, while iptables prints --, which iptables_parse relies on, so all fields starting with opt are shifted in the parsed rule data structure:

    And the firewall is configured to block all outgoing IPv6 traffic                                                            # features/step_definitions/tor.rb:146
      {"rule"=>"0     0 ACCEPT     tcp      lo     *       ::1                  ::1                  tcp dpt:4101", "pkts"=>0, "target"=>"ACCEPT", "protocol"=>"tcp", "opt"=>"lo", "in_iface"=>"*", "out_iface"=>"::1", "source"=>"::1", "destination"=>"tcp", "extra"=>"dpt:4101"}
      {"rule"=>"0     0 ACCEPT     tcp      lo     *       ::1                  ::1                  tcp spt:4101 state RELATED,ESTABLISHED", "pkts"=>0, "target"=>"ACCEPT", "protocol"=>"tcp", "opt"=>"lo", "in_iface"=>"*", "out_iface"=>"::1", "source"=>"::1", "destination"=>"tcp", "extra"=>"spt:4101 state RELATED,ESTABLISHED"}
      The IPv6 table's INPUT chain contains some unexptected rules:
      0     0 ACCEPT     tcp      lo     *       ::1                  ::1                  tcp dpt:4101
      0     0 ACCEPT     tcp      lo     *       ::1                  ::1                  tcp spt:4101 state RELATED,ESTABLISHED.

This prevents us from adapting tor_enforcement.feature for Jessie: we would need to whitelist IPv6 traffic to lo there, because we had to allow some of it to make Orca work.

Subtasks

History

#1 Updated by intrigeri 2015-07-08 02:15:00

#2 Updated by intrigeri 2015-08-02 09:05:39

  • Due date set to 2016-01-15

#3 Updated by intrigeri 2015-08-02 09:06:00

  • blocks #8668 added

#4 Updated by intrigeri 2015-08-26 05:55:35

  • Deliverable for set to 268

#5 Updated by intrigeri 2015-11-19 22:33:17

  • Assignee changed from anonym to intrigeri

I’m going to give it a try since it’s the only blocker to see features/tor_enforcement.feature pass.

#6 Updated by intrigeri 2015-11-19 23:27:07

  • Status changed from Confirmed to In Progress
  • Assignee changed from intrigeri to anonym
  • % Done changed from 0 to 10
  • QA Check set to Info Needed

Our current parser uses the output of ip6tables -L -n -v, which is not machine readable enough for our needs. I could not find an iptables rules parser in Ruby that clearly states that it’s compatible with IPv6 (ip6tables). I’m not thrilled at the idea of seeing us write another custom iptables rules parser, given the outcome of this first attempt. I think our best option may be to use an existing parser written in another language, e.g. those are available in Jessie:

… and write whatever wrapper script we need around the library we pick, to output whatever info we need to JSON or YAML that our test suite’s support code could read.

anonym, what do you think?

#7 Updated by intrigeri 2015-11-24 16:24:52

  • blocks #8538 added

#8 Updated by anonym 2015-12-07 04:41:58

  • Assignee changed from anonym to intrigeri
  • % Done changed from 10 to 40
  • QA Check changed from Info Needed to Ready for QA

Wow, I completely missed your comment here. Any way, I converted the existing parser to something I believe is a lot more robust (based on XML via iptables-xml). I hope you find it ok:

e9fefde Kill the now unused `iptables_parse()`.
e877253 Convert `iptables_parse()` instance.
c2d0b3e Convert `iptables_parse()` instance.
da339d8 Convert `iptables_parse()` instance.
7e889a3 Convert `iptables_parse()` instance.
7345d9d Introduce a new XML-based iptables parser.

#9 Updated by intrigeri 2015-12-07 05:29:16

> Any way, I converted the existing parser to something I believe is a lot more robust (based on XML via iptables-xml).

Sounds exciting! I’ll try to review it shortly :)

#10 Updated by intrigeri 2015-12-07 15:08:17

At least it passes tor_enforcement.feature here, which is a good start :)

#11 Updated by intrigeri 2015-12-07 17:08:30

  • Status changed from In Progress to Resolved
  • Assignee deleted (intrigeri)
  • Target version changed from Tails_1.8 to SponsorS_M4
  • % Done changed from 40 to 100
  • QA Check changed from Ready for QA to Pass

Looks good to me, great work! I didn’t explicitly try to break it with corner cases, but the code indeed looks sane and more robust than a home-brewn regexp parser :)

#12 Updated by intrigeri 2016-06-30 08:12:22

  • Target version deleted (SponsorS_M4)