Message-ID: <3DF9165145FACB4C96977FF650C1E904096336AB@its-mail1.its.corp.gwl.com>
From: james.burnes at gwl.com (Burnes, James)
Subject: OpenBSD 'pf' port (was FreeBSD heap to Linux)

Excellent.  Is it kernel specific? Also, is it kosher to mix freebsd
license with GPL? (stand back while flame throwers are cranked up ;-)

But I'd really be interested if anyone has tried porting 'pf' as a
netfilter kernel module.  I can't stomach iptables anymore, but short of
using something like FirewallBuilder sometimes I can't get away from it.

I've considered porting 'pf' to Linux 2.6, and while netfilter looks to
be a faily powerful mechanism for firewalls, I'm afraid it would be a
huge project.  Probably better to rewrite the whole program from scratch
and make it a work-a-like.  The translation of the class-based-queueing
mechanisms looks particularly daunting.

If anyone is currently working on this I'd like to hear from them.  It's
not that I don't like OpenBSD, it's just that there are some projects
where I need a decent firewall to be co-resident with Linux.  IPTables
is not an option unless it's my only option.

I have considered some sort of virtualizing mechanism.  I wonder if it
would be easier to clone user-mode-linux into a user-mode-openbsd
personality and then install an OpenBSD 'flashdist' image.  That way the
firewall is completely virtualized away from the normal OS environment.

Probably better to take this to the firewalls or bsd lists.

j. burnes


> -----Original Message-----
> From: Georgi Guninski [mailto:guninski@...inski.com]
> Sent: Wednesday, January 28, 2004 9:04 AM
> To: full-disclosure@...ts.netsys.com
> Subject: [Full-Disclosure] Port of FreeBSD heap to Linux
> 
> There is a port of the freebsd heap to linux at:
> http://www.guninski.com/wares/free10.tar.gz
> md5sum free10.tar.gz
> c20d5f2d4790fdecc6d1f0005aaa9d2d  free10.tar.gz
> 
> The README:
> 
> Port of FreeBSD's heap implementation to Linux.
> 
> This is a linux port of the heap implementation originally written
> by phk@...eBSD.ORG.
> 
> Why: It is considered safer than the linux heap implementation.
> double free bugs does not seem exploitable, some heap overflows also
may
> not be exploitable.
> Of course it *does not* give 100% protection against heap mischief.
> 
> Ported to linux by Georgi Guninski guninski@...inski.com
> 
> INSTALL
> 1. make
> 2. cp mallib.so /usr/local/lib
> 3. LD_PRELOAD=/usr/local/lib/mallib.so PROGRAM
> or export LD_PRELOAD=/usr/local/lib/mallib.so
> 
> 
> 
> mallib.so should be readable and executable by all users.
> 
> to check if the new heap is loaded:
> cat /proc/<pid>/maps
> mallib.so should be in the output.
> 
> to use the new heap globally:
> put in /etc/ld.so.preload
> /usr/local/lib/mallib.so
> 
> 
> To change the heap options
> # cd /etc
> # ln -s <options> /etc/malloc.conf
> 
> The shared library works with static binaries also.
> 
> NOTE:
> if you use it globally, start a program after editing
/etc/ld.so.preload
> to
> check whether it works before booting.
> If there is a problem, you may need to remove mallib.so from
> ld.so.preload.
> 
> DON'T OVERWRITE mallib.so if it is running globally - box may freeze!
> 
> Globally works on debian and redhat.
> 
> 
> KNOWN BUGS:
> 
> 1.memalign() is just a wrapper to malloc() which is not correct.
> 2.does the mutex stuff work?
> 3.The only bug I have encountered is a X server and KDE crash on
debian.
> 4.What are the best options for the bsd heap - /etc/malloc.conf
> 
> TODO:
> 1. Make memalign work as expected.
> 
> CREDITS
> gbr, peio
> for testing
> 
> --
> georgi
> 
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.netsys.com/full-disclosure-charter.html

Powered by blists - more mailing lists