Re: [Fwbuilder-discussion] [BULK] Re: Open remote fwb

[Frank W. <Fra...@ct...>]

On Wednesday 26 September 2007 17:05:22 Vadim Kurland ? wrote:
> This thread was rather active, so here is a little summary.
>
> centralized storage for .fwb data files seems to be important
> feature, requested by many.
>
> I'd rather avoid any implementation that relies on comparing XML files.
>
> Frank's solution based on old firepoint project is very close to what
> I thought of doing, except instead of external wrapper and install/
> compile  scripts it should be integrated into the GUI. Access to the
> policy server is via ssh, there should be no special software running
> on the policy server, just a few simple shell scripts. These scripts
> should come with fwbuilder package but user should be able to provide
> their own. This is very similar to the built-in installer framework,
> hopefully a lot of code can be reused.
>
> With this approach version control can run on the policy server as
> well. The GUI just needs to execute RCS (or other version control
> system) commands remotely, via ssh.
>
> The question of reliable locking of the data file that has been
> "checked out" still remains. Perhaps running some version control
> system that also provides locking (such as RCS) on the server will be
> sufficient.


This is very good news!
The firepoint daemon (which is just a perl script, really) does the policy=
=20
locking for me (only one RW checkout of a policy is allowed). There is also=
=20
some level of security in it, but some of this is probably overkill:
*) The server only permits connections from a list of known IP addresses.
*) The server does its own user management (lisst of allowed users and=20
passwords). When you checkout a policy file, the client gets a random key.=
=20
This key (and the username) are checked when you attempt to check in again.
*) All communication is done via  IO::Socket::SSL.

Several months ago, I found that newer Linux distro's don't carry perl-gtk(=
1)=20
anymore, and porting to Gtk2 was less than straightforward. At the time I w=
as=20
tempted to redo it from scratch, and my idea was to do most of it via scp/s=
sh=20
just like you intend now. I don't really recall why (probably laziness), bu=
t=20
somehow I just gave in and ported the gui part of the firepoint client to=20
perl-gtk2.=20

When you dive into this, my request would be the following: the 'server'=20
should also handle the 'library' files, ie collections of objects that are=
=20
shared across different fwb files. That would be a real step forward for me.

A lot of this belongs into the fwbuilder gui, but, as I didn't have the=20
ambition modify it, I have always hacked my way around it so I can still us=
e=20
your vanilla releases. For example, I have an xsl that spits out the IP=20
address of interface that is marked 'external' so that the server knows whe=
re=20
to upload the policy.... A lot of this can be done more elegantly in=20
fwbuilder, so it's really good news that you want to look into this....


Have a nice day,


=46rank


=2D-=20
_______________________________________________
 Centre de Technologie de l'Education
 29 avenue John F. Kennedy
 L-1855 Luxembourg-Kirchberg
 email: Fra...@ct...
 t=E9l.: +352 478-5973
 fax: +352 333797
 _______________________________________________