Date: Mon, 14 May 2001 18:09:28 +0300 From: Ruslan Ermilov <ru@FreeBSD.ORG> To: Peter Pentchev <roam@orbitel.bg> Cc: Igor Podlesny <poige@morning.ru>, freebsd-security@FreeBSD.ORG Subject: Re: ipfw rules and securelevel Message-ID: <20010514180928.A52742@sunbay.com> In-Reply-To: <20010514180201.C453@ringworld.oblivion.bg>; from roam@orbitel.bg on Mon, May 14, 2001 at 06:02:02PM %2B0300 References: <Pine.LNX.4.33.0105141802230.18115-100000@apsara.barc.ernet.in> <10320318256.20010514212856@morning.ru> <19322552168.20010514220610@morning.ru> <20010514170927.A849@ringworld.oblivion.bg> <5523460344.20010514222118@morning.ru> <20010514180201.C453@ringworld.oblivion.bg>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, May 14, 2001 at 06:02:02PM +0300, Peter Pentchev wrote:
> On Mon, May 14, 2001 at 10:21:18PM +0700, Igor Podlesny wrote:
> >
> >
> > > On Mon, May 14, 2001 at 10:06:10PM +0700, Igor Podlesny wrote:
> > >>
> > >> >> Dear friends,
> > >> >> Even in securelevel 3 I can bypass ipfw rules. In securelevel 3 I
> > >> >> as root can change the variable "net.inet.ip.fw.enable" using sysctl. When
> > >> >> I run a command
> > >>
> > >> >> sysctl -w net.inet.ip.fw.enable=0
> > >>
> > >> >> It disables the ipfw rules.
> > >>
> > >> >> Is it a feature or hole in freebsd.
> > >>
> > >> > doesn't matter how it is called, only matters how it hurts... (it does)
> > >>
> > >> >> please help
> > >>
> > >> the "patch" (hard to call it a patch, but nevertheless) is adding
> > >> CTLFLAG_SECURE to the relevant definition of the node:
> > >>
> > >> this diff out is for 3.5 stable:
> > >>
> > >> 92c92
> > >> < SYSCTL_INT(_net_inet_ip_fw, OID_AUTO, enable, CTLFLAG_RW,
> > >> ---
> > >> > SYSCTL_INT(_net_inet_ip_fw, OID_AUTO, enable, CTLFLAG_RW|CTLFLAG_SECURE,
> >
> > > Patches/diffs are usually much easier to review and apply if they are
> > > in context or unified diff format - this helps when the patch is made
> > > against a possibly changed file :) And.. well.. it might be obvious
> > > to you (in this case it's pretty obvious to figure out ;), but still
> > > it helps a lot to mention which file(s) the patch is against :)
> >
> > oh, you're right :)
> >
> > it was
> > /usr/src/sys/netinet/ip_fw.c
> >
> > unified diff:
> >
> > --- /usr/src/sys/netinet/ip_fw.c.orig Fri Mar 23 19:44:27 2001
> > +++ /usr/src/sys/netinet/ip_fw.c Mon May 14 22:15:55 2001
> > @@ -89,7 +89,7 @@
> >
> > #ifdef SYSCTL_NODE
> > SYSCTL_NODE(_net_inet_ip, OID_AUTO, fw, CTLFLAG_RW, 0, "Firewall");
> > -SYSCTL_INT(_net_inet_ip_fw, OID_AUTO, enable, CTLFLAG_RW,
> > +SYSCTL_INT(_net_inet_ip_fw, OID_AUTO, enable, CTLFLAG_RW|CTLFLAG_SECURE,
> > &fw_enable, 0, "Enable ipfw");
> > SYSCTL_INT(_net_inet_ip_fw, OID_AUTO,one_pass,CTLFLAG_RW,
> > &fw_one_pass, 0,
>
> Yup, this patch is much clearer, and I see no real reason against
> committing it. Actually, I think that even more of those sysctl's
> should be flagged as 'secure' - e.g. the ones related to logging.
>
Hmm, but I think that for (securelevel < 3) the transition should
still be allowed. The correct fix then would be:
Index: ip_fw.c
===================================================================
RCS file: /home/ncvs/src/sys/netinet/ip_fw.c,v
retrieving revision 1.164
diff -u -p -r1.164 ip_fw.c
--- ip_fw.c 2001/04/06 06:52:25 1.164
+++ ip_fw.c 2001/05/14 15:04:12
@@ -96,9 +96,19 @@ LIST_HEAD (ip_fw_head, ip_fw_chain) ip_f
MALLOC_DEFINE(M_IPFW, "IpFw/IpAcct", "IpFw/IpAcct chain's");
#ifdef SYSCTL_NODE
+
+static int
+sysctl_fw_enable(SYSCTL_HANDLER_ARGS)
+{
+
+ if (req->newptr && securelevel >= 3)
+ return (EPERM);
+ return sysctl_handle_int(oidp, arg1, arg2, req);
+}
+
SYSCTL_NODE(_net_inet_ip, OID_AUTO, fw, CTLFLAG_RW, 0, "Firewall");
-SYSCTL_INT(_net_inet_ip_fw, OID_AUTO, enable, CTLFLAG_RW,
- &fw_enable, 0, "Enable ipfw");
+SYSCTL_PROC(_net_inet_ip_fw, OID_AUTO, enable, CTLTYPE_INT|CTLFLAG_RW,
+ &fw_enable, 0, sysctl_fw_enable, "I", "Enable ipfw");
SYSCTL_INT(_net_inet_ip_fw, OID_AUTO,one_pass,CTLFLAG_RW,
&fw_one_pass, 0,
"Only do a single pass through ipfw when using dummynet(4)");
--
Ruslan Ermilov Oracle Developer/DBA,
ru@sunbay.com Sunbay Software AG,
ru@FreeBSD.org FreeBSD committer,
+380.652.512.251 Simferopol, Ukraine
http://www.FreeBSD.org The Power To Serve
http://www.oracle.com Enabling The Information Age
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010514180928.A52742>