should looking at an interface with 'ifconfig' trigger a ?change ?

Robert Watson rwatson at
Sat Aug 9 11:05:59 UTC 2008

On Fri, 8 Aug 2008, Oliver Fromme wrote:

> Andrew Thompson wrote:
> > Pete French wrote:
> > > > The bce driver is not properly generating link state events.
> > >
> > > OK, that explains why it doesnt failover - but why does looking at it 
> > > with ifconfig make a difference ? surely that should be 'read only ?
> >
> > ifconfig will cause the media status to be read from the hardware at which 
> > time the link change is generated as it is different to the stored value.
> Shouldn't that be considered a security flaw?  After all, you can perform 
> "ifconfig $IF" inside a jail to list the interface configuration, but you're 
> not allowed to make any changes.
> Given your description above, it means that it is possible to modify the 
> interface configuration (cause a failover) from within a jail.  That's not 
> good.  I think that needs to be fixed, or at the very least it needs to be 
> properly documented.

While obviously a serious bug (link state notifications are required so that, 
for example, aggregates can take interfaces going down, or up, into account), 
I don't see this as a security flaw.  The administrator intends for the higher 
abstraction state transition to be triggered by the lower one, but the problem 
is that the time it takes for that notification to take place is effectively 
non-deterministic.  If they didn't want the higher level transition to take 
place, then they shouldn't have configured it that way.  On the whole, we make 
no attempt to limit covert channels from jails to the host system, and there 
are potentially lots of interactions between them, so its not a violation of 
the security policy for jails.  That said, this definitely needs to be fixed, 
as things like fail-over and routing updates happen pretty poorly otherwise.

The epistemology of security flaws is complicated, needless to say...

Robert N M Watson
Computer Laboratory
University of Cambridge

More information about the freebsd-stable mailing list