netdev - rfkill vs. interface up

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

Date:	Tue, 19 May 2009 14:32:11 +0200
From:	Johannes Berg <johannes@...solutions.net>
To:	linux-wireless <linux-wireless@...r.kernel.org>
Cc:	Dan Williams <dcbw@...hat.com>, netdev <netdev@...r.kernel.org>
Subject: rfkill vs. interface up

Hi,

More thoughts on rfkill ...

So we were thinking it would be sensible to just force interfaces down
on rfkill, which is of course possible, and then reject attempts to set
the interface UP while killed.

There's just one problem with that -- when you un-rfkill, does the
kernel set interfaces UP again?

If not -- how would we possibly handle 'iwconfig .. txpower off'? We're
mostly handling it like rfkill now afaict, but 'iwconfig .. txpower on'
wouldn't be able to do anything properly.

If yes -- how do we know which interfaces to set UP? However we turn it,
userspace can then not disable an interface regardless of rfkill state,
which gets really confusing.

Therefore, I don't think we can simply set interfaces down on rfkill
with the current scheme.

On the other hand, the interfaces really are dysfunctional in rfkill and
we really need more integration.

I'm happy to give up on 'iwconfig wlan0 txpower on/off' entirely, simply
refuse supporting it (return -EINVAL if txpower.disabled) and then use
the first scheme where rfkill forces the interface down but userspace is
responsible for enabling it again. This is asymmetric, but I don't see
what else to do.

Thoughts?

johannes

Download attachment "signature.asc" of type "application/pgp-signature" (802 bytes)