A really minor possible security weakness. This is a simplified sequence of events as I see it happening: 1) Kernel initializes udev 2) udev identifies devices and sets up /dev 3) system init runs through <rc sysinit>, then <rc boot> 3) in the boot runlevel, hotplug is started -- before iptables is run? (iptables has "before net" set, but not "before hotplug" 4) hotplug takes the messages from udev and activates the appropriate devices 5) to do the activation, hotplug uses the handling scripts in /etc/hotplug 6) Notice in /etc/hotplug/net.agent, the interface gets brought up with --quiet suppressing stdout 7) iptables is activated in the normal course of the boot runlevel setup (before net) 8) then, it appears that net.eth0 is run with the "stop" command and you see the interface going down, since it's not configured to be started at the boot runlevel 9) the system initialization switches to the default runlevel 10 ) net.eth0 is started normally, with iptables already running This appears to create a situation where eth0 can be up for some length of time without the system's iptables rules in place, creating the opportunity for some poor sad sack to have a go at anything that might be up (for example, something else started by hotplug?). A really minor issue, but probably not safe given the ability for hotplug to run things outside the normal initialization process. Reproducible: Always Steps to Reproduce: 1. Enable udev support in a 2.6 kernel, and emerge the hotplug tools that use it to load drivers. Disable the "--quiet" option for /etc/hotplug/net.agent. 2. Boot the system -- watch for the ethernet card coming up via hotplug 3. pay close attention to the timing of when hotplug starts the interface versus when iptables is run in the boot runlevel. Actual Results: for a brief time, eth0 was up with no iptables protection. Expected Results: the init scripts should not give hotplug or a misconfigured system a chance to bring an ethernet interface up without iptables protection. I don't know if the <net.eth0 --quiet> call in /etc/hotplug/net.agent is necessary, but it would help not to suppress that output, I think. Always better to see what hotplug is doing automatically. The only reason I noticed this issue was the odd "shutting down eth0" message that I was getting at boot time from net.eth0 being run with the "stop" command (after hotplug had started the interface).
Created attachment 42637 [details, diff] Patch to make net.agent ignore interfaces that should be brought up in a runlevel.
In my opinion, hotplug should not start any network interfaces that are started by scripts linked into any of the runlevel directories - if you put an interface into a runlevel with "rc-update add eth0 default", there's an expectation that the interface won't come up until the runlevel is started. I have attached a patch to net.agent that will cause it to ignore any interfaces that have been set to start up in a runlevel.
I would go one step further and say that I don't think hotplug should be bringing up any interfaces at all -- that should be controlled by the runlevel scripts. Allowing hotplug to (silently!) bring up interfaces I think would be possibly dangerous, and at the very least unexpected for most users.
I don't agree with that. I find it most useful that I can plug in a PCMCIA WiFi card, and it starts automatically.
Sounds like there are requirements on both sides. My fix works for Remy, as long as he doesn't put the net.* entry in the runlevel. But I can see people with the requirement "only hotplug this interface if we're in this runlevel". It seems like we need a map of runlevels at which a specific interface should/should not be active. Perhaps we can make the semantics "if the interface is in a certain runlevel, when that runlevel becomes active set the "hotplugging allowed for this interface" flag and bring up the interface if the hardware is plugged in. When you leave the runlevel for another that does not have the interface in it, unset the hotplug flag and shut down the interface if active." This should give the best of both worlds, though I don't have a clue of how to implement it :)
Over the holidays I took another look at this. Give the attached patch a try -- basically, it blocks hotplug from starting network interfaces in runlevels unknown,0,1,2, and 6. This removes the "boot" runlevel problem (when run at that point, /sbin/runlevel returns "unknown" because /var/run/utmp isn't available) and keeps network interfaces from starting in runlevels where they aren't protected. It also gives total freedom to normal users to hot-plug away, and I even added messages to the script so that you can see when net.agent is at work. I also removed the --quiet on all the net.$INTERFACE calls so people can see what's going on. Someone with more knowledge of the initscripts and bash should *definitely* go over this when/if it gets included.
Created attachment 47056 [details, diff] modifies /etc/hotplug/net.agent to keep network interfaces from being started in non-network runlevels
I'm going to mark this as a dupe as there's more discussion going on at bug #78495. Feel free to give input there to an alternative patch which does not affect hotplug but has a similar affect as your patch. *** This bug has been marked as a duplicate of 78495 ***
