From owner-freebsd-ipfw  Tue Jul 27 12:49:47 1999
Delivered-To: freebsd-ipfw@freebsd.org
Received: from aurora.sol.net (aurora.sol.net [206.55.65.76])
	by hub.freebsd.org (Postfix) with ESMTP
	id 8225F151BF; Tue, 27 Jul 1999 12:49:36 -0700 (PDT)
	(envelope-from jgreco@aurora.sol.net)
Received: (from jgreco@localhost)
	by aurora.sol.net (8.9.2/8.9.2/SNNS-1.02) id OAA13262;
	Tue, 27 Jul 1999 14:49:12 -0500 (CDT)
From: Joe Greco <jgreco@ns.sol.net>
Message-Id: <199907271949.OAA13262@aurora.sol.net>
Subject: Re: securelevel and ipfw zero
In-Reply-To: <199907271915.NAA26782@mt.sri.com> from Nate Williams at "Jul 27, 1999  1:15:11 pm"
To: nate@mt.sri.com (Nate Williams)
Date: Tue, 27 Jul 1999 14:49:12 -0500 (CDT)
Cc: jgreco@ns.sol.net, nate@mt.sri.com, hackers@freebsd.org,
	freebsd-ipfw@freebsd.org
X-Mailer: ELM [version 2.4ME+ PL43 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-ipfw@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

> > > > > One could argue that accounting numbers in a firewall shouldn't be
> > > > > trusted, but I won't argue that point since the firewall is often the
> > > > > most 'natural' place to stick network accounting software.
> > > > 
> > > > If you can't trust something in the kernel, then you just can't trust
> > > > anything at all.
> > > 
> > > It isn't the kernel that's zero'ing the counters. :)
> > 
> > Accounting numbers in a kernel firewall _should_ be trustable, and on that
> > basis, one can clearly make an argument for separating the logging count
> > from the accounting count - which should never be zero'ed, at least in
> > securemode.
> 
> One could argue that 'logging counters' in a firewall _should_ be
> trustable as well.  You've argued against it, but I'm not convinced that
> your opinion (or mine) is enough to consider it a 'bug'.
> 
> > I'm not saying your desire for per-rule counters is invalid, I'm just not
> > of that same mindset.  But it does seem clear that it would be useful to
> > have a mechanism to restart the logging after an IPFW_VERBOSE_LIMIT
> > throttle.
> 
> It would be useful.  But, is it's usefulness more important than being
> able to rely on 'logging counters' being valid?  (You argue no, but I'm
> not convinced...)
> 
> Again, it's not a fix, it's a feature.  Not being able to mess with
> counters (logging or otherwise) is a feature.  It may be a feature that
> you can do without, but that decision is not to be made lightly.

I'm _saying_ to create a completely separate counter which has nothing to
do with accounting.  The counter which you "trust" for any purposes can be
the accounting counter, which nobody can mess with in securemode.  The
logging counter is merely to allow VERBOSE_LIMIT whether or not the logging
throttle should be engaged, and therefore you can EITHER:

1) Set a global VERBOSE_LIMIT mechanism and:
	a) allow your logging counter to be reset, or
	b) allow your limit to be raised to re-enable logging
2) Set a rule-oriented VERBOSE_LIMIT mechanism and allow each rule's
   logging counter to be reset.

So, what's your vote?

(I'm wondering if maybe we can do a combined 1a and 2 of some sort)

... Joe

-------------------------------------------------------------------------------
Joe Greco - Systems Administrator			      jgreco@ns.sol.net
Solaria Public Access UNIX - Milwaukee, WI			   414/342-4847


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-ipfw" in the body of the message