[linux-elitists] Integrating the firewall and the package manager?

Karsten M. Self kmself@ix.netcom.com
Wed Apr 13 02:01:47 PDT 2005

on Tue, Apr 12, 2005 at 01:13:32PM -0700, Jim Richardson (warlock@eskimo.com) wrote:
> On Tue, 2005-04-12 at 11:28 -0700, Don Marti wrote:
> > (Forgive me for polluting your inbox with what seems like an obvious
> > idea, but some people might want to print it out for the "neener,
> > neener, Prior Art on you, you obvious-idea-patenting pinhead" box.)
> > 
> > Problem: malware can spread without getting root.
> > 
> > Solution: Solution?  What is this, a banner for a tradeshow booth?
> > There are no "solutions", just extra hops on the attack path.
> > 
> > I think it's possible to combine the problem of setting up local
> > firewall rules with the easier problem of using the package manager
> > correctly.
> > 
> > Basically, the system boots up with all tables default DROP.  Then,
> > when any daemon starts, its init script is responsible for setting
> > up any rules necessary for it to do its job.  If you start a
> > local-only daemon, the script should be smart enough to parse the
> > daemon's config file and only allow traffic that the daemon will.
> > If you set up an MTA with a smarthost, the script should be smart
> > enough to allow outgoing port 25 only to the smarthost. 
> > 
> > (If the config file is impossible to parse, add a
> > "--just-parse-your-freaky-config-file-and-dump-an-iptables-rule-please"
> > command-line option to the daemon itself.)
> > 
> > Likewise, the init script is responsible for taking the rules down
> > after stopping the daemon.
> > 
> > Any package that needs to do something network-wise but doesn't have
> > an init script would be responsible for adding a script in
> > /etc/hey-let-me-talk-on-the-network-please and all those scripts
> > would get run at appropriate times.
> > 
> > For example, the package manager itself could add a rule allowing
> > outgoing connections on port 80 to distro-updates.example.org -- but
> > if the system didn't have any other web clients installed, it
> > couldn't make any other outgoing port 80 connections.

> This seems like an interesting approach, but it would likely be distro
> dependent, not that it's a bad thing though. 

Not particularly.

We've already got infrastructure for starting services (sysv init), and
for managing services via inetd/xinetd.  About the only real step
required is a  standard code drop into the sysv init start/stop and
(x)inetd wrappers which opens or closes ports, as well as a
specification for what ports are concerned.
> One question would be some of the more convoluted transport protocols
> like p2p and IM stuff, which are often problematic in this area. 
> Although for servers, this sounds like a great idea. 

Actually, my thought was desktops, which all-to-frequently run _way_ too
much stuff.... 

/me looks around guiltily.

The tricky bits I'd see are dual/multi-homed servers, particularly those
for which differing access policies would apply to different interfaces.

Beaujolais, Don!


Karsten M. Self <kmself@ix.netcom.com>        http://kmself.home.netcom.com/
 What Part of "Gestalt" don't you understand?
    Please, M'sieur, it is a little game we play. They put it on the
    bill, I tear up the bill. It is very convenient.
    - Casablanca
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://allium.zgp.org/pipermail/linux-elitists/attachments/20050413/9d209abc/attachment.pgp 

More information about the linux-elitists mailing list