Hi,
[not Cc'ing other mailing-lists because 1. what I'm going to discuss
has little to do with the initial request, and is mostly
Tails -specific; 2. I don't fancy cross-posting entire discussions.
Let's report back to the other lists once we've reached some kind of
conclusion here.]
anonym wrote (22 Dec 2015 16:21:50 GMT) :
> Patrick Schleizer:
>> Wouldn't it be possible, and simpler, to block all networking with
>> iptables to prevent early MAC leaks so kernel module blacklisting could
>> be avoided?
After spending hours hunting down #9012 today, I must say I'm
interested in any solution that does not rely on un-blacklisting
kernel modules :]
> I'm not sure it would be simpler. The module blocking approach
> definitely makes some other parts of the implementation simpler and
> decoupled so the MAC spoofing system more or less can be plugged into
> the existing Tails without modifying other parts.
Right. I'd like to keep this property, and I think we can keep it
while changing the way we block outgoing connections during boot.
How about this minimal change:
a) We remove the modules blacklist logic.
b) We set up a boot-time firewall that blocks all outgoing connections
to non-loopback interfaces.
c) We keep the udev MAC spoofing hook as-is: when the user hasn't made
a decision yet, we don't do anything; if the user has made
a decision already, we apply it.
d) We make all our NM hooks exit early unless the user has made their
MAC spoofing decision already, just like they most of them exit
early unless we're up'ing a non-loopback interface.
e) Once the user has made their decision wrt. MAC spoofing (that is,
in tails-unblock-network, run by PostLogin, just as it is now):
1. We record that decision in some place where all legitimate
interested parties (at least the MAC spoofing udev hook, and our
NM hooks) can check it out.
2. We trigger udev, wait for it to settle. The goal here is to have
the udev MAC spoofing hook run.
3. We replace the boot-time firewall with the production one.
4. We start NetworkManager.
For coldplugged network adapters: in theory, udev settle guarantees
that the firewall is unlocked, and NM is started, /after/ the MAC
spoofing hook has been run.
For hotplugged network adapters: in theory, udev should not make
a device available to NM before the MAC spoofing hook has run; that's
exactly what our current implementation relies on, to make it safe to
hotplug such devices, even though the corresponding modules are *not*
blacklisted anymore when they're plugged, right?
It feels to easy, so perhaps I'm missing what makes it hard?
> Also, it feels safer to rely on the lack of code (i.e. no module loaded)
> than more code (iptables (via ferm) and netfilter blocking absolutely
> everything for some device, even low-level wireless active probing etc).
I think that the above proposal addresses all other problems you
raised with the netfilter-based idea, so unless I missed a serious
problem, then this argument might be the only strong one we have in
favour of our current implementation (aside of the fact that our
current implementation exists and works in most cases already, of
course :)
> Also note that we want to support hotplugging network devices safely
> (w.r.t. MAC spoofing) after boot and logging in, so the firewall rules
> would have to be updated dynamically upon when a device is added (and
> removed!), which seems complex and makes me feel a bit uneasy.
I'd rather not do that, indeed. But I don't think we need it.
I've found it helpful to think about how we currently handle
hotplugged devices: we don't update the blacklist dynamically, we just
delete it once the user has made their decision. And then, we assume
that we can do the right thing even once the blacklist has been
removed, so I don't see why we would need more precise, per-device
rules, than what I'm suggesting above (boot-time vs.
production firewall), if we were to switch to
a netfilter-based approach.
Cheers!
--
intrigeri
