In article <[EMAIL PROTECTED]>,
Matthew G. Marsh <[EMAIL PROTECTED]> wrote:
>On 27 Mar 2002, Zygo Blaxell wrote:
>> 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?
It's just a label which you can match in iptables, which you could
use with, or instead of, the iptables built-in --in-interface and
--out-interface matches. You could even do both, like:
iptables ... --in-interface eth+ -m label --in-label SECURE-LAN ...
to match only Ethernet devices (eth+) with the SECURE-LAN label.
>What is the difference between this and renaming the interface?
The main difference is that many interfaces can have the same label,
but names have to be unique to each interface.
On the other hand, if you renamed all your interfaces to "GLORK01",
"GLORK02", etc, then you could use 'iptables --in-interface GLORK+'
to have a similar effect.
Also, a label might actually work where renaming the interface does not.
Renaming interfaces seems to be very limited and/or broken, especially if
you try to build QoS tables on renamed interfaces (the tc and ip commands
seem to want you to use the interface's original name), or if you attempt
to apply a name to an interface after it is configured and up (as is
normally the case with cipcb+ and ppp+), and especially if it's the kind
of interface where 'ifdown' is synonymous with 'destroy the interface'
(as is normally the case with PPP and CIPE).
Last time I checked, if I try to rename a PPP interface, I either lose
the connection, get an error, or it doesn't work, depending on various
combinations and orders of {down, ip-link-set-name, up}. Another problem
occurs when you have user-space daemons involved in setting up interfaces
that don't know the new name of the interface to bring it down again.
Basically the nice thing about having a label which exists in its own
namespace separate from the name is that other parts of the kernel and
user-space that rely on interfaces having constant names throughout
their lifetimes don't get confused.
>> - 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?
I didn't, but I didn't think I stopped someone from writing iptables
rules that would implement something like that anyway. The ifup script
could for example synthesize iptables chains on the fly to implement a
dynamic security policy, then label the interface when the chains are
in place.
On the other hand, I see no reason (other than IMHO unnecessary
implementation complexity) not to allow multiple labels per interface,
now that I think about it. That would mean that there would be "iflabel
add IFNAME LABEL" and "iflabel remove IFNAME LABEL" userspace commands,
instead of just one command to replace the existing label with a new one.
If you could put multiple labels on an interface, then you could slap
on labels like e.g. "dynamic", "static", "untrusted", "trusted",
"wireless", "uplink", etc. and then have lots of fun writing iptables
rules for "dynamic uplink" or "static untrusted wireless" cases.
On the other hand, how many distinct security policies are you likely
to have? On dozens of firewalls I've built I've had at most four
basic security policies on a single machine (internet, DMZ, private
LAN (which includes VPN's and private dial-up PPP), and wireless),
and they all happen to be mutually exclusive.
--
Zygo Blaxell (Laptop) <[EMAIL PROTECTED]>
GPG = D13D 6651 F446 9787 600B AD1E CCF3 6F93 2823 44AD
