netdev - Re: [RFC] Stable interface index option

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Wed, 2 Dec 2015 09:03:35 -0200
From:	Marcelo Ricardo Leitner <marcelo.leitner@...il.com>
To:	Hannes Frederic Sowa <hannes@...essinduktion.org>
Cc:	Maximilian Wilhelm <max@...2324.org>, netdev@...r.kernel.org
Subject: Re: [RFC] Stable interface index option

Hi,

On Wed, Dec 02, 2015 at 12:58:58AM +0100, Hannes Frederic Sowa wrote:
> Hello,
> 
> On Tue, Dec 1, 2015, at 23:43, Maximilian Wilhelm wrote:
> > How should net-snmp handle cases where new interfaces come up on old
> > and now unused numbers? What should it report? That would escalate the
> > problem a lot IMHO.
> 
> ifindexes are only reused when the ifindex allocator wraps around which
> should hopefully take a while and that is exactly my point.
> 
> In general the ifindexes are designed to not be reused very fast. Most
> ifindex usage is in socket layer where one specifies which way a packet
> should go in sendto/msg calls to override routing lookups or use link
> local addresses. Imagine an application looks up an interface and
> determines the ifindex to send out data to an ipv6 link local address
> (which needs the ifindex obviously). If we don't bias the ifindex
> selection during device creation time the app will get an error and
> won't race with other tunnels being setup and can handle that
> accordingly because new tunnels simply have new ifindexes until the
> per-namespace counter wraps around. If we have name based policies we
> have to audit user space applications how they do interface name
> selection to protect them against reusing interface names. Based on your
> mail you simply already do ensure that interface names are unique, so
> your monitoring software should use just them.
> 
> I simply see this feature being misused way too easily.

This is very similar to processes and their pids. On (small) embedded
systems it's common that a given process will always have the same pid
after boot. Then for some reason a process is restarted and you want it
to have that same pid, which is not good.

Same semantics would apply, I think. Monitoring software has to know how
to handle with that change and cope with it.

I don't know the details but I know that it's also possible to monitor
processes via SNMP, meaning that monitoring apps must already do that
for processes, then why not for interfaces?

  Marcelo

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html