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]

Date:	Mon, 27 Apr 2009 16:55:58 -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:

>Jay Vosburgh wrote:
>>> 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.
>>   
>That may be fine.  I suppose you'll also be ignoring admin state changes
>for the
>underlying devices in the VLAN code?  Ie, if eth0 goes admin down, you won't
>change the eth0.5 vlan to be admin down?

	Ok, I did a bit of testing on this, and I don't believe the
"update vlan carrier state" patch I did changed anything in this regard.

	Without the patch, given a configuration of eth0 with eth0.600
and eth0.700 stacked above, the sequence "ifconfig eth0.700 down;
ifconfig eth0 down; ifconfig eth0 up" results in eth0.700 being up at
the end, and both eth0.600 and eth0.700 being down when eth0 is down (up
and down here referring to IFF_UP, not carrier state).  The VLAN event
handler (vlan_device_event) deliberately sets all VLAN devices to match
the real device when the real device goes up or down.

	I still agree that this is a bit counterintuitive, but the patch
doesn't change the VLAN behavior in this regard.

	With the patch, the same thing happens, but the carrier state
also changes to match (without the patch, the VLAN interfaces remain
carrier up the whole time).

	I'm reluctant to mess with this behavior without knowing why it
works this way; there may be a good reason for it that I'm not aware of.

	-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