1. Rationale

The current FirewallRules system is a pretty thin abstraction over ferm, and has an ad-hoc parser with a number of built in limitations. Even after only having a dozen or so rules, it is becoming clear that managing firewall rules will quickly become burdensome both for members and admins.

Based on current patterns of requests, there a few things to consider:

• We need a way to define groups of rules that members can trivially request
  • default ports for shell user (http, vcs software, mail, ssh, ...)
  • common rules for certain cgi applications or special uses (e.g. wordpress always needs to contact wordpress.org for full functionality)
• Don't want to tie configuration to physical nodes (e.g. moving to a new shell server)
• Restrict users to having rules on certain nodes (statically enforced)
• Members should be able to grant themselves "safe" rules without any admin intervention
  • allowing members to grant themselves safely marked rule groups seems like a good start

A few wish list considerations:

• Want to store per-node firewall config for system services (apache, exim, imap, etc.)
  • Ideally, also store common port config (afs, kerberos, domtool, etc.)

Conclusion: the current fwtool implementation would require duplicating a lot of functionality already present in the support machinery for the domtool domain type. A new syntax for user rule files would need to be created (or tons of hackish supporting code) so ...

The only (in)sane way forward is to create a domtool container for firewalls to manage rules. This has distinct advantages:

• Takes advantage of current domtool infrastructure for pushing configs
• The domtool language is quite nice and has the needed functionality for abstracting groups of users, common config, etc.
• Lays the groundwork for using domtool to perform node management in addition to domain management

CategorySystemAdministration CategoryWorkInProgress