Mailinglist Archive: opensuse (3337 mails)

< Previous Next >
Re: [opensuse] openSUSE @ Google Summer of Code 2006
  • From: Jerry Westrick <jerry@xxxxxxxxxxxx>
  • Date: Sun, 30 Apr 2006 12:44:01 +0200
  • Message-id: <200604301244.01450.jerry@xxxxxxxxxxxx>
On Thursday 27 April 2006 20:59, Christoph Thiel wrote:
> Hi everyone,
> openSUSE has just been accepted at Google Summer of Code 2006!

> We are now looking for ideas, proposals, projects, etc. around openSUSE
> and SUSE Linux, that could be worked on in Google Summer of Code. As the
> period of application for SoC is already very short, we need to get our
> proposals for project online May 1st, 2006, at the latest.
> So, for example, if you are missing a certain YaST module, or a special
> feature in the distribution, speak up now!
> Our proposals will be publish on shortly.
> Regards
> Christoph
Late Proposal....

I propose SUSE Firewall 3.

The purpose of this module would be to allow an advanced user to move
onto a more advanced firewall system with out having to resort to iptables

This module will work with the SUSE FW2 definitions, But offer an additional
GUI to define advanced (to professional) firewall configuration settings.

My proposal is that to incorporate to do this.
FWBuilder has one of the best gui's for building firewall available.
It is often compared to SyncPoint (Mega $ closed source system,
defacto standard).

Additionally, FWBuilder has a momentum, (ie. a large group of Firewall
/ security experts who are constantly improving and checking the "Rule

I've mentioned this in the FWBuilder developer lists, (as a prove of concept).
They seam to approve of the Idea, and immediately started thinking about
changes to FWBuilder that would make it work better for the project.

Here the jist of our discusions:

Proposal build a interface between YAST fw definitions and FWBuilder:
> Can you use all FWBuilder functions via the API?

>> No.
>> ...
>> You can also look at the fwbedit utility in the fwbuilder 2.1, we've
>> added ability to create objects in it so one could do this just by
>> calling this simple command line tool. You need to check the latest
>> code out of cvs to look at 2.1 code.

> fwbedit sounds like just what I need...

>> but you still need to add rules ...  Fwbedit does not do that, it was
>> intended as a simple command-line tool to manage objects. There were
>> requests from users for a way to add objects in bulk, say, from a
>> spreadsheet or some configuration file they could parse.

> Okay, but I think I can get around that as follows:
> The firewall will be pre-configured with rules. The configuration  
> is done by
> using the pre-defined rules based the following service groups:
> Service Group                 Description
>   Ext2Srv                             Services (ports) Allowed From Internet
to Server
>   Ext2Lcl                             Services (ports) allowed from Internet
to Local Network
>   Lcl2Ext                             Services (ports) allowed from Local
network to Internet
>   Lcl2Srv                             Services (ports) allowed from Local
Network to Server
>   Client2Srv                  Serives (ports) allowed from Client Pc's to
>   Srv2Ext                             Services (ports) allowed from Server
to Internet
>   Srv2Lcl                             Services (ports) allowed from Server
to Local Network
> Then with fwbedit I can just need to add the ports to the correct  
> predefined
> group, and recompile...
> Does this sound feasible?

>> yes, absolutely. Good idea.
>> do not forget about an option "Ignore empty groups". The thing is, if  
>> any of these groups becomes empty, you do not want the rule to treat  
>> it as "any".

> Note: This is not meant to replace the fwbuilder gui, but as a  
> method of
> transition from the SUSE firewall definitions to fwbuilder...
> I still ain't figured out how SUSE yast will work with fwbuilder  
> after the
> transition, but, one step at a time...

>> may be yast does not have to work with it after all. You can start  
>> with preconfigured set of standard rules in the policy and make your  
>> code recognize them and put objects in the groups you listed above.  
>> The rest of the policy can be managed by fwbuilder GUI outside of  
>> yast should user want to expand it. The user will be able to add  
>> rules before or after your rules. There is a risk of user deleting  
>> rules used by yast, for now you can only put some scary comment and  
>> color them red or something to make it clear they are used by yast. I  
>> wonder if I should expand the scope of the attribute "read-only" to  
>> rules...


That's my proposal folks...


< Previous Next >