Hi Scott,
Thus spoke Scott C. Best:
>
> Hmmm. I think we're speaking about different things. :)
Quite possibly :-)
> Let me see if I can remember my thinking on this...a firewall
> system includes these things:
>
> 1. A OS with packet-filtering capability (eg, okay, Linux ;)
> 2. A command interface to that capability (eg, ipchains)
> 3. A base ruleset, usually defined in terms of #2 (eg,
> a *order-dependent* list of ipchains commands).
> 4. User customizations to augment #3.
>
> What I've heard discussed over the last few weeks is:
> "what sort of user interface can LEAF provide to make the
> installation of #3 and the creation of #4 easier for the
> non-learned user?".
Good.
> My opinion has been that the design of this user
> interface can be simplified if it is independent of #2. It
> would read and write to a platform-neutral format, and so
> the talk naturally comes around to XML for that. In that
> format, we'd specify the whole of #3, including its
> required order dependencies (which is as Ray pointed out).
What is the point of using a platform-neutral format such as XML to
represent the firewall if what's being represented is very
platform-specific? Wouldn't it be better for the UI to generate output
that is entirely platform-neutral and have a backend process translate
this platform-neutral representation into a platform-specific ruleset
(#3). I can understand representing #4 in terms of platform-specific
rules but those rules can be opaque with respect to the XML representation
(e.g., just blobs of text). This would be analagous to what I do in the
various /etc/seawall/<chain> files; they can contain whatever
platform-specific commands that the users wants included in the associated
chain and the "behind the scenes" translation script (the firewall
script in the case of Seattle Firewall), simply passes them to the shell
for execution at the proper point in building the chains.
This approach would allow the UI to be substantially independent from the
target platform (ipchains, iptables, <whatever Rusty comes up with next>,
...).
> We'd also store "user intentions" which can be much higher
> level as you suggest: "FTP_SERVER=192.168.1.2" is all it
> should take.
>
> I'm a big proponent of "solve the UI" problem, so I'm
> willing to swallow the pill that comes with it: if we *do*
> make this step away from defining a firewall in terms of
> ipchains, then there is a "magic happens here" piece of code
> that translates the XML data back into it. The overall complexity
> of the task is unchanged; I'm just advocating the shift of
> the complexity from the "what you see everyday" UI to the
> "behind the scenes" translation script/process.
In that, we're in total agreement.
-Tom
--
Tom Eastep \ Alt Email: [EMAIL PROTECTED]
ICQ #60745924 \ Websites: http://seawall.sourceforge.net
[EMAIL PROTECTED] \ http://seattlefirewall.dyndns.org
Shoreline, Washington USA \___________________________________________
_______________________________________________
Leaf-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/leaf-devel
