On 27 Mar 2002, Zygo Blaxell wrote:
[snip]
> Matching IP address is really just a cheap substitute for having a real
> interface label. Match-by-IP doesn't really solve the problem, it only
> happens to work in cases where match-by-interface-name doesn't. Neither
> can solve all problems that can be solved by labels.
>
> A label would be a property of an interface, like an interface name
> or IP address. Labels would be matched by iptables, but not assigned
> by iptables. Labels would be assigned to an interface using a mechanism
> similar to ifconfig, or 'ip name'.
>
> Interestingly enough, there is an 'ip name' function (possibly left over
> from my email conversation with Alexei circa 2.1.120 when I upgraded
> from ipfwadm to ipchains and first observed this problem) but nobody
> seems to remember what it's for, so it breaks a lot of stuff, and it was
> only useful in specific circumstances to begin with. IMHO so much stuff
> inside and outside the kernel now assumes that interface names are
> constant that allowing interfaces to be renamed is no longer a good idea.
It is for exactly what you are referring to - the ability to "name" and
interface by whatever suits your fancy. In fact I even allow this in my
networking scripts as part of the interface configuration data.
Essentially it point up the fact that eth0 is meaningless insofar as the
usage of the interface is involved.
fe: I run a snort instance on an interface. I name the interface snort
using the ip name function and end up with an interface named snort. So I
can then use this name in the SNMPv3 scripts that maintain statistics for
that interface.
As with DNS the interface name/label is merely a mapping from the machine
to a human convenience. FWIW the code is:
ipupint() {
. /etc/sysconfig/network-scripts/$1
/sbin/ip link set $DEVICE down
DEV=$DEVICE
if [ ! -z $DEVNAME ]; then
/sbin/ip link set $DEVICE name $DEVNAME
DEV=$DEVNAME
fi
for ADDRESS in $IPCIDR
do
/sbin/ip addr add $ADDRESS broadcast + dev $DEV
done
/sbin/ip link set $DEV arp on
/sbin/ip link set $DEV up
}
where the configuration file looks like:
#!/bin/sh
#>>>Device type: ethernet
#>>>Variable declarations:
DEVICE=eth0
DEVNAME=snort
IPCIDR="172.16.1.1/16"
SPECIAL=0
STARTME=1
#>>>End variable declarations
> Consider this shell fragment in /etc/ppp/ip-up.d/firewall, which assigns
> label SYS-2-INTERF-D to a PPP interface if the pppd command was invoked with
> the environment variable $SOME_MAGIC_VARIABLE set to yes.
> If SOME_MAGIC_VARIABLE is not set, then we don't assign any label:
>
> if [ "$SOME_MAGIC_VARIABLE" = yes ]; then
> iflabel $PPP_IFACE SYS2-INTERF-D
> fi
>
> We might have an ethernet interface attached to a secure LAN, and some
> CIPE interfaces. We distribute these in the various ifup scripts:
>
> iflabel eth0 SECURE-LAN
> iflabel cipcb0 SECURE-LAN
> iflabel cipcb1 SECURE-LAN
Now this could be very confusing - I think you are stating that if I want
to apply a general security profile to SECURE-LAN I may and then if I want
additional specific security on cipcb0 I apply it directly? What happens
then if I flush the general profile? Would it also delete my specific
applications?
> Example: allow interfaces with "SYS-2-INTERF-D" label to talk to
> firewall, and allow free communication between labelled "SECURE-LAN"
> interfaces and labelled "SYS-2-INTERF-D" interfaces:
>
> iptables -t filter -A INPUT -m label --in-label SYS-2-INTERF-D -j ACCEPT
>
> iptables -t filter -A OUTPUT -m label --out-label SYS-2-INTERF-D -j ACCEPT
>
> iptables -t filter -A FORWARD -m label --in-label SECURE-LAN --out-label
>SYS-2-INTERF-D -j ACCEPT
>
> iptables -t filter -A FORWARD -m label --out-label SECURE-LAN --in-label
>SYS-2-INTERF-D -j ACCEPT
>
> Note the similarity to the standard '-i' and '-o' interface match
> operators--we are still really matching interfaces here, only the
> namespace has changed.
>
> The label MUST automatically disappear if the interface goes down,
> to prevent race conditions. Consider what happens if labels don't
> automatically disappear, and your non-secure PPPoE uplink and your dialup
> secure PPP private LAN connection both go down at the same time (which
> is actually quite likely if you are using the same physical cable for
> 56K dialup and DSL), and both are configured to reconnect automatically.
> If ppp0 and ppp1 get swapped, ipchains will be matching packets according
> to what _was_ connected to the interfaces instead of what _is_ there now.
> This is no better than just rewriting iptables rules matching interface
> names in the ip-up and ip-down scripts, and it has the same security
> problems.
>
> > What do you think?
>
> - each interface can have only one label.
What is the difference between this and renaming the interface?
> - many interfaces may have identical labels. iptables will
> match any interface with a given label, similar to '-i ppp+'
> matching all interface names starting with 'ppp'.
And how do you allow these interfaces to also have additional specific
security profiles?
> - one entry in the label namespace is reserved for the kernel,
> which will assign that label--and only that label--to each
> interface as it comes up *and* down. This label might have
> a text string value such as "default" or "NONE".
>
> - an interface's label can be changed at any time.
> Packets will retain the same input-interface-label and/or
> output-interface-label under the same atomicity rules as
> input-interface-name and output-interface-name.
>
> - an arbitrary 32-bit integer is as good as a text string label.
> Labels represent site-specific policies, and most people will
> have a small number of those which are easy to enumerate.
>
> Hope this one doesn't get truncated ;-)
This is an interesting discussion...
> --
> Zygo Blaxell (Laptop) <[EMAIL PROTECTED]>
> GPG = D13D 6651 F446 9787 600B AD1E CCF3 6F93 2823 44AD
>
--------------------------------------------------
Matthew G. Marsh, President
Paktronix Systems LLC
1506 North 59th Street
Omaha NE 68104
Phone: (402) 932-7250 x101
Email: [EMAIL PROTECTED]
WWW: http://www.paktronix.com
--------------------------------------------------