netdev - Re: vlan: update vlan carrier state for admin up/down

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <30658.1240619463@death.nxdomain.ibm.com>
Date:	Fri, 24 Apr 2009 17:31:03 -0700
From:	Jay Vosburgh <fubar@...ibm.com>
To:	Ben Greear <greearb@...delatech.com>
cc:	Patrick McHardy <kaber@...sh.net>,
	"David S. Miller" <davem@...emloft.net>,
	Linux Netdev List <netdev@...r.kernel.org>
Subject: Re: vlan: update vlan carrier state for admin up/down

Ben Greear <greearb@...delatech.com> wrote:

>Suppose that someone has eth0, eth0.2 and eth0.5 admin UP.
>
>Then, sets eth0.5 admin DOWN.
>
>Later they set eth0 down and up for some reason.
>
>Would eth0.5 now go admin UP?

	Yes, with the patch applied, it does.

>If so, I think that is not a good idea and could possibly be considered
>a security issue.  I think instead there should be a new flag for VLANs
>that is 'preferred-admin-state'.  To be UP, both the underlying device
>and the preferred state must be UP.  That should allow bouncing eth0
>w/out affecting the eventual admin state of the VLANs on eth0 in
>the example above.

	I dunno if it's a security issue, but I'd agree it's wrong.  I
looked, and I suspect that a couple of judiciously placed "if
(dev->flags & IFF_UP)" bits ought to sort things out by simply not
copying the carrier state to the upper level VLAN device if that device
is down.  Unless somebody works this up over the weekend, I'll work that
out on Monday.

	When the vlan device (eth0.5 in the above example) later is set
up, it'll do the right thing for its own carrier state.

>For what it's worth, it seems that other virtual devices, such as VIFS
>on a wifi radio, might need the same sort of behaviour.

	Would they actually need a flag, or could it be worked out just
by checking their IFF_UP-ness?

	-J

---
	-Jay Vosburgh, IBM Linux Technology Center, fubar@...ibm.com


--
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