On Fri, 7 Nov 2008, Theo de Raadt wrote:

quoted text
>> >Peter N. M. Hansteen wrote:
>> >> Harald Dunkel <harald.dunkel@aixigo.de> writes:
>> >>
>> >>> Sorry to wake this thread up again, but this problem is a severe
>> >>> security risk. IMHO it is unacceptable that a hardware failure on
>> >>> one NIC of a firewall can put the whole network at risk, just because
>> >>> the mapping between NICs and interface names gets mixed up, and PF
>> >>> suddenly treats the Internet as a subnet of the company LAN.
>> >>
>> >> Semi-random reordering of network interfaces would be a severe
>> >> problem, no doubt.  However, my hazy memory was that reordering would
>> >> not occur as you describe, but ICBW, please correct me if this has
>> >> actually been demonstrated to happen.
>> >
>> >I can post 2 dmesg logs of the same machine with the NIC
>> >names mixed up. Somehow 2 NICs disappeared on a reboot. On
>> >the next reboot they were back. Attached is the diff.
>> >
>> >In the bad configuration the NIC with 00:30:48:d2:9a:06 is
>> >called "em2", in the good one it is called "em4". Maybe you
>> >can imagine how PF screws up, if this NIC would have been
>> >physically connected to the Internet.
>> >
>> >Surely it is unusual that a NIC "disappears" somehow. Maybe
>> >there is something wrong with my hardware, but this can always
>> >happen. I would like to have a secure setup even if there is a
>> >hardware failure.
>>
>> Network configuration has bugged me a bit ever since I started using
>> OpenBSD, not just the real security issue that Harald Dunkel points out
>> but general ease of administration issues.  For example, on a typical
>> single-NIC system one ought to be able to set up a standard
>> configuration and not care which make/model of NIC is installed.
>
>You are joking right?  In that case you use the "egress" interface
>group.  It works perfectly on all machines with one network interface,
>and follows the default route.

Maybe I'm just confused, but my recollection is that one needs to set up
the appropriate hostname.<interface-name> to enable the interface before
the "egress" interface group works.

This single-NIC case is admittedly a minor one, but it would eliminate
one of the few (that I can think of) things about running a basic
OpenBSD system that requires any "arcane" setup.

quoted text
>Or would you rather use eth0?

Since I never mentioned eth0, the answer is pretty obviously "no".

quoted text
>> Perhaps most of these issues could be dealt with by changing the network
>> configuration procedure to have a hierarchy of interface-configuration
>> files rather than just hostname.<interface-name>.
>
>Oh, like eth0 and eth1 and eth2?

See above.

quoted text
>> If hostname.<mac>
>> were used if the hardware MAC matches, then hostname.<interface-name>,
>> then (say) hostname.only if there's only one NIC found, the sysadmin
>> could assign interfaces to groups and use those group names everywhere,
>> and so not need to use the actual interface names at all.
>
>So right now you have hardware that is disappearing.  What happens when
>you get hardware where the MAC reading is not 100% reliable.  New problem,
>and a new solution?

Actually, it's other people who have the problem.  I was just
speculating on how to minimize its harmful effects.

One can always postulate a hardware (or other) failure which can't be
dealt with by whatever the current software may be; the question is
whether it happens often enough and is serious enough to be worth doing
something about.  Or if it suggests a change which is worthwhile in
itself and also solves the problem.

quoted text
>> This appears to be a fairly simple change.  Does it sound reasonable to
>> people with more knowledge of OpenBSD networking?
>
>No, it is not reasonble.  You are inventing problems at a very high
>level just because some very low level pci-related bug is making some
>of your devices not reliably show themselves.

No, I'm thinking about a general way for those people who care about it
to tie pf rules, etc, to specific physical interfaces, regardless of
what other devices are installed or configured in a system.

	Dave

-- 
Dave Anderson
<dave@daveanderson.com>