Ah - having an interface name naming scheme that, instead of just being
a counter, e.g. CDCE + 0 -> 1 -> ... = "cdce0", denoting the physical
slot where the device is connected, e.g. CDCE + USB root-hub: 0 + slot:
17 + address: 4 = "cdceur0s17a4", would do the job too.
On 2017-06-02 00:24, Tinker wrote:
> Hi,
>
> What I meant was, it's fairly easy for interface numbers (e.g. NIC A
> as CDCE0 and NIC B as CDCE1) to become exchanged.
>
> With lots of unluck, there could be mechanical stress on USB ports so
> that they would rearrange spontaneously so NIC B would become CDCE0
> and NIC A would become CDCE1.
>
> Or more probable, an ignorant user would intentionally replug his
> devices but the change of order of interfaces would be unintentional
> to him, and then when he ifconfig/dhclient:s his interfaces, very bad
> things could happen.
>
> This is not a big deal, but it does add one more thing to think about,
> and in extreme corner cases it could be a security problem - God
> forbid you'd have a public network on CDCE0 and a private network on
> CDCE1 and then a little mistake causes everyone's medical records etc.
> to be leaked on the Internet.
>
>
> The same would apply to USB serial ports (UART:s) and probably some
> other hardware -
>
> I was talking to someone who was worried that it (unintended device
> ordering) could happen even to PCI devices though I guess that's
> overkill.
>
> His solution is to enforce device names by using different hardware,
> though that kind of illustrates the problem rather than resolve it,
> doesn't it.
>
>
> OpenBSD leaves IP configuration as manual work to the user so OpenBSD
> itself won't mess it up for you, so this is not a per-se OpenBSD
> problem.
>
> But maybe OpenBSD could help people do it right. Interface number
> hard-binding to a particular device descriptor (MAC/USB serial etc.)
> would solve it.
>
> Interface name aliasing would work too (hardbound to descriptor).
>
>
> Anyhow I just wanted to bring up the potential problem.
>
> (Also Peter - this is not specifically a PF problem, however, how
> would you use egress as part of the solution?)
>
> Thanks,
> Tinker
>
> On 2017-05-30 07:04, Peter Hessler wrote:
>> On 2017 May 29 (Mon) at 02:13:57 +0000 (+0000), Tinker wrote:
>> :Hi misc@,
>> :
>> :For pluggable devices such as USB NIC:s, is there any way to make
>> OpenBSD
>> :bind a particular device based on its MAC or USB serial number or the
>> like
>> :variable, to a particular interface or device filename?
>> :
>> :E.g. MAC X is prebooked as cdce0, and MAC Y as cdce1 , and external
>> USB
>> :harddrive with serial number Z as /dev/sd0 and the one with serial
>> number A
>> :as /dev/sd1 (and plugging in other devices would automatically).
>> :
>> :(For storage devices there's the DUID-based mounting already though,
>> so I
>> :guess those are a non-issue.)
>> :
>> :Some things in the OS are specified per interface/device name, e.g.
>> PF rules
>> :(e.g. "pass in proto tcp from any to cdce0 port 123 rdr-to cdce1 ..",
>> "match
>> :out on cdce0 from 192.168.0.0/16 to any nat-to cdce0"), so having the
>> :interface numbers garbled on replug may be an unnecessary reason to
>> reboot?
>> :
>> :Would be happy to learn any best practice here, thanks,
>> :Tinker
>> :
>>
>> match out on egress from 192.168.0.0/16 to any nat-to (egress)
>> ^^^^^^ ^^^^^^^^
>>
>> the interface group "egress" is added to the interface a default route
>> uses. Wrapping that with (), will ensure that interface is updated
>> when
>> the default routes uses a different interface.
No comments:
Post a Comment