Bolt on for whonix_firewall - best place to put files?

Development
7

[quote=“Patrick, post:4, topic:2222”]
The risk of changing firewall rules while refactoring is minimal because it can be verified:[/quote]

Not so sure that’s true - at development time, yes. At run time, most anything could get their fingers in there. Isn’t this really suggesting some form of iptables intended / current diff run called by whonixcheck?

[quote]
www.whonix.org

Dev/Firewall Refactoring

How to refactor Whonix’s firewall.[/quote]

I don’t think I’m well following that article / its intent.

It reads more like a iptable verification process than a refactoring. Am I missing something?
(never mind, why not just use iptables-save | cut {something or other}. In either case a post-run munging to minimize diff hits is going to be needed.)

Does ‘Dev/Firewall Refactoring’ need to itself be refactored to individually thread the items (you so excellently) note?

8

I would source them. Not call as separate scripts. Easier with shared variables.

We should not mix up the config folder /etc/whonix_firewall.d with other possible future folders for dispatching pre or post hooks. That would be non-standard. We being the only ones doing that.

The following gives maximum ability to add pre/post hooks everywhere.

funct1() {
...
}
funct2() {
...
}
funct3() {
...
}
main() {
   funct1
   funct2
   funct3
}

...source some .d folder(s)...

main "$@"

When sourcing of a .d folder is done early, it allows to overwrite any shell function. Including the main function to change ordering what is run and when.

genmkfile has a mechanism to automatically run funcname_pre and functname_post functions - if they have been declared in a .d folder. So you can have pre and/or post actions for any shell function that is run anyhow. And if that is not enough, you can also re-implement / overwrite the whole default shell function.

genmkfile/usr/share/genmkfile/make-helper.bsh at bbe8e989a29f1620a71e13b2ed6717ceb09d8825 · Kicksecure/genmkfile · GitHub

If this is still too unclear, I can try implementing a pseudo example script called “super-flexible” which shows as far as I can imagine how far hooking can go.

The other question with firewall code injection, pre/post hooks is when to dispatch them? When you want to dispatch them depends on what you actually want to implement.

For example obviously running the hook after $iptables_cmd -A INPUT -j DROP would not allow you to modify the input chain. (Unless doing trickery that would look awful.) On the other hand, do you want your hook dispatched before or after $iptables_cmd -t nat -A PREROUTING -i "$int_if_item" -p udp --dport 53 -j REDIRECT --to-ports "$DNS_PORT_WORKSTATION"? Again it depends on what you want to implement.

9

It feels easy enough, for example, to split out env. var setting within whonix_firewall to something like /etc/whonix_firewall.d/10_setenvvars, but I don’t grok enough of whonix to be confident that doing so is appropriate / consistent / desired. e.g. The multiple scripts you note would need to understand that pinned down filename.

Let alone, each script would have to duplicate that a var exists / is set. Each var dev. change would need reflection in each script dependent upon the file.

I can work on this if desired, but these feel like global whonix environment settings, of which the whonix_firewall particulars are but a subset. Is this even a reasonable mechanism to perpetuate?

(Again, I’m not arguing, nor arguing one way or another. I don’t profess to know.)

10

Dev/Firewall Refactoring - Kicksecure purpose is only a description on how to ease development.

Let’s say the line was

$iptables_cmd -A INPUT -j DROP;

And I want to change it to.

$iptables_cmd -A INPUT -j DROP

Or the whole thing gets converted into a shell function. (Just a demonstrative example.)

Then the intent of the firewall script change was not to change actual iptables rules. It was code refactoring only. And to make sure it was only code refactoring and no actual iptables chain change, the above instructions should work. So when adding some new hook code theoretically or when splitting the firewall script into multiple files or whatever it is easy to verify, that only the layout was changed, not the actual iptables chain. It does not go beyond that. No leak testing etc. However, it’s sane to have an iptables dump of Whonix 12 and then compare it with Whonix 13 etc.

11

[quote=“Patrick, post:8, topic:2222”]
If this is still too unclear, I can try implementing a pseudo example script called “super-flexible” which shows as far as I can imagine how far hooking can go.[/quote]

No, by including the example you did, I get a glimpse of what you’re saying - and can appreciate it. Refinement / specifics can come if/should such be considered for acceptance.

Yep. Thus the next step after the file location would be a whonix_firewall change to call them (at the end).

Yep. That’s why I expect to propose whonix_firewall changes to set such rules in env. vars.

e.g.
IPT_FILT_INP_LASTRULE=‘INPUT -j DROP’
$iptables_cmd -A $IPT_FILT_INP_LASTRULE

And scripts can:
$iptables_cmd -D $IPT_FILT_INP_LASTRULE
$iptables_cmd -A {other good stuff}
$iptables_cmd -A $IPT_FILT_INP_LASTRULE

12

You are suggesting…

  • set all rules as env vars first
  • allow overwriting with a .d folder that gets sourced
  • $env_var_1, $env_var_2 (more pretty names) etc. below?

I guess that would be super difficult to read if we did that for each and every time executing $iptables_cmd.

13

AGREED. And not something I would want to suggest. Simpler is better. (Mind you, I find whonix_firewall pretty easy to read as it stands now. So not sure about others looking for simpler. But I do take your points of multiple callers, and the value of functions().)

The idea of a bolt on (addon?), optionally chosen / added functionality, is to leave the base strictly alone / completely transparent to those who didn’t take specific steps to enable that functionality. While enabling those who do choose to choose the option, to be able to do so.

Unfortunately, inherent to such a facility is being able to leverage the good stuff that is already there (e.g. env. vars like INT_IF), and hooks for calls to such if present. Which is to say, changes to current scripts. (That null out if the option not chosen.)

Thus, I take your point, and agree, that a separate .d directory is the correct answer, rather that inserting changes into current, to segregate such off, and have the least impact upon base, possible.

14

In that case I would have a simpler and more readable implementation in mind. Before the reject iptables rule… If function whonix_firewall_input_hook_end exists, execute it. (Open for better function name.)

if [ "$(type -t whonix_firewall_input_hook_end)" = "function" ]; then
   whonix_firewall_input_hook_end
fi

That way you could ship a file /etc/whonix_firewall.d/40_something.conf:

whonix_firewall_input_hook_end() {
   ... your stuff ...
}

allow overwriting with a .d folder that gets sourced

15

Ah. OK, I get you now - initial sourcing picks up function definitions (but not execution thereof) at that time.

However, this feels overly complex. I’m not saying unnecessarily so, I wouldn’t know - the more I look the more I realize how many larger concerns are in play (e.g. qubes vs whonix, poking at the packages you noted, debian + lintian), the more expensive it appears gazing into the contributing room from the doorway. And the less inclined I am to cross that threshold. (No doubt, after several years of contributing, looking back on that comment will feel very newbie and wasn’t really something all that intimidating. Not so much so, today, though.)

Here, in this complexity, not doing as you suggest feels like it brings: prove {this} out {fini}, next then prove {that} out {fini}. vs the complexity, inserting many little bits in many places, and having to prove the whole out every time. i.e. Every time one turns around there’s another new entire ecosystem to grok before one can begin to think about where they’re trying to go. (I’m not saying this isn’t inherent / inevitable, merely daunting.)

Hmmm. This doesn’t handle the case of multiple addons. Unless it is the responsibility of each function declarer to chain to the next. Or leads to what essentially become callbacks.

Arrays, instead?

func mypostcallstuff() {
mystuff;
}

hook_end_funcs += mypostcallstuff();

foreach hook_end_funcs call hook_end_funcs(@);

[Pardon the really bad pseudo-code.]

  • problem, something developed later wants to insert itself earlier in the chain, the running of which breaks something developed earlier but now called later. (Perhaps this is an inevitable Catch 22.)

Is there a separate forum / wiki / phabircator (?) area where this discussion should be moved to / is already ongoing?

In the mean time, see next messages, trying to keep discussion points / threads here separate.

16

[quote=“Patrick, post:4, topic:2222, full:true”]
I have been wondering for some time now if the firewall script should be split. A lot sections are being used by multiple packages, whonix-gw-firewall, whonix-ws-firewall and vpn-firewall.[/quote]

I was startled some while back when I realized that, e.g. whonix-gw-firewall and whonix-ws-firewall, did not ‘source’ a common bit of code across both.

From comments here, it seems that such is desirable. How to go about getting from current to there?

So, the article is really just expressing the desire for a iptables sanity check process.

I expect I can come up with such - I’ve already gone almost blind trying to sanity check scripts, and verify pre- and post- script iptables impact.

However, I’ve no idea where / how to plug the right things to the right places in the whonix git. i.e. Inherently, it feels like such a facility would get incorporated into whonixcheck (much like the extra / unwanted package checks). However, if one chooses to use an ‘addon’, ‘good’ [Warn?Diff:NotDiff] becomes a moving target I don’t see how to incorporate. Never mind where/how to incorporate such into whonixcheck at all, and a default inclination to keep my sticky fingers out of it entirely.

17

Dev/Firewall Refactoring does not need to go into whonixcheck. It’s a lot simpler process than you might think.

  1. developer stores an iptables rules dump
  2. developer does some refactoring in the firewall script
  3. developer stores another iptables rules dump
  4. diff the dumps

Or…

  1. developer stores an iptables rules dump of Whonix 12
  2. developer stores another iptables rules dump of Whonix 13
  3. diff the dumps

It’s so simple it may even go without saying as an implicit expectation when making changes.

18

I take your point, but I’m not so sure.

[At the least, presumably one would want to call such as part of the build process. iptables rule changes possibly inadvertently killing connectivity isn’t something you want to leave to ‘hope the developer ran this check’. Oops, they forgot.]

Many things post-installation can munge on iptables, deliberately such as ufw, pgl, or any other firewall, or inadvertently (and hidden) by accident or nefariousness. Since, for example, I don’t run qubes, I have no way to check qubes impact. One after installation insertion of -j ACCEPT would seriously endanger ones objective in choosing whonix.

In any case, where to plug in any results? The wiki item, then transform / transmit to {destination} when such becomes apparent?

19

It could be part of the build process by policy. I.e. running a test suite, which we don’t have. But not part of the image build script, because it runs in chroot and we don’t want to modify the build system iptables rules.

Anyhow. It’s a separate discussion that deserves a separate topic. For refactoring whonix firewall script (move to functions or similar), Dev/Firewall Refactoring really is enough.

Also whonixcheck (which is somewhat a replacement for the lack of test suite) could indeed be useful to check if the loaded iptables rules match a hardcoded iptables dump. Yes, with additional firewalll add-ons that would be hard. Then these firewall add-ons could ship a dump that also gets verified. (iptables-dumps.d folder checked by whonixcheck or so.) But then multiple firewall add-ons gets hard. Mutliple firewall add-ons and dumping, that kind of flexibility might be stretching what the Whonix project may be able to implement. That is more like an iptables super flexibility project. Lots of work to do. Also deserves additional thread.

20

OK. Thank you.

Except … I still don’t fathom a wiki page (sans talk pages) serving such a purpose. Is there a wiki page around that shows such use?

21

Not sure I am following. Wiki page showing use of what? Anyhow. I guess you can have any new wiki page if it helps. Tell me the link and I’ll create it.

22

Herein / this (forum) thread, has been a discussion. You note, “It’s a separate discussion”, and “Dev/Firewall Refactoring really is enough”. (And I don’t disagree.)

Thus my “I still don’t fathom a wiki page (sans talk pages) serving such a purpose.” If you have a wiki page link where such a discussion takes place, I expect it will help me understand how you mean the wiki page is enough.

23

Just create a new forum thread for that. And link that from here.

24

port to netfilter-persistent?:
https://phabricator.whonix.org/T487

25

Time to move this/these to new thread(s)?

e.g. I can’t tell from phabricator if phabricator link is a discussion or a go. And it’s unclear whether this would negate the need for an iptables-dump diff’er.

26

Was just hinting that a related ticket/discussion has been created.

A discussion because the title ends with a question mark. But even if there wasn’t a question mark, if someone has a better idea…

Not at all, because it’s an orthogonal issue.