Firewall Wizards mailing list archives
Re: Securing a Linux Firewall
From: BORBELY Zoltan <bozo () andrews hu>
Date: Wed, 24 Jul 2002 11:18:11 +0200
Hi, On Wed, Jul 24, 2002 at 12:13:52AM -0400, Carson Gaspar wrote:
--On Tuesday, July 23, 2002 4:01 PM -0600 John McDermott <jjm () jkintl com> wrote:This, I believe, presumes that you are *100% sure* that the given binary can grant no additional privs. I am seldom that sure about software.If it is not setuid, and not setgid, it _can't_ grant you extra privs (ignoring funky capability ACLs and the like).Then you should care even more. Why leave something around that cen be exploited even if you personally don't know how to use it in an attack? I prefer to err on the side of caution and remove anything not needed.If it's not running as a daemon, and grants no additional privs, how can it possibly be "exploited"?
It can be a library which is imported by one of the running programs or daemons. It can be a simple program which is executed by one of the programs. Are you sure you know all of the dependencies of the running programs? If you put only the required binaries you can be sure.
I may be confused, but to me that sounds like "make a list of the few programs the firewall needs and only put those on the jumpstart CD". This means removing all unused packages from the system before creating the "jumpstart"-like CD.No. "The few programs the firewall needs" is significantly larger (especially under Solaris) than "The few setuid/setgid programs the firewall needs". I assert that the first set is very large, and is very difficult to maintain as the OS changes. You are free to disagree with my assertion.
This is an important thing. How can you be sure the next version of the OS won't execute a new binary of won't be linked to a new shared library? If you install only the minimum you can be sure.
But you _don't_ _have_ _to_ _audit_ _everything_. Things that don't run at boot, and grant no additional privs, are just noise. They are inert, and there is no earthly reason to care about them. This is the core premise of my approach. All I have to audit are about 5 binaries, and a (sadly much larger) list of shared objects that they depend upon.
See above. Bye, Zoltan BORBELY _______________________________________________ firewall-wizards mailing list firewall-wizards () honor icsalabs com http://honor.icsalabs.com/mailman/listinfo/firewall-wizards
Current thread:
- Re: Securing a Linux Firewall, (continued)
- Re: Securing a Linux Firewall Kevin Steves (Jul 26)
- RE: Securing a Linux Firewall Bruce Platt (Jul 23)
- RE: Securing a Linux Firewall Carson Gaspar (Jul 23)
- RE: Securing a Linux Firewall Paul Robertson (Jul 23)
- Re: Securing a Linux Firewall Brian Hatch (Jul 23)
- Re: Securing a Linux Firewall John McDermott (Jul 23)
- Re: Securing a Linux Firewall Marcus J. Ranum (Jul 23)
- Re: Securing a Linux Firewall Marcus J. Ranum (Jul 23)
- RE: Securing a Linux Firewall Carson Gaspar (Jul 23)
- Re: Securing a Linux Firewall Brian Hatch (Jul 23)
- Re: Securing a Linux Firewall Carson Gaspar (Jul 24)
- Re: Securing a Linux Firewall BORBELY Zoltan (Jul 24)
- RE: Securing a Linux Firewall Bill Royds (Jul 24)
- Re: Securing a Linux Firewall Kyle R. Hofmann (Jul 24)
- Re: Securing a Linux Firewall Stephen P. Berry (Jul 26)
- Re: Securing a Linux Firewall R. DuFresne (Jul 26)
- Re: Securing a Linux Firewall Gwendolynn ferch Elydyr (Jul 24)
- Re: Securing a Linux Firewall Stephen P. Berry (Jul 25)
- Re: Securing a Linux Firewall Gwendolynn ferch Elydyr (Jul 25)
- RE: Securing a Linux Firewall David Lang (Jul 24)