Re: [Tails-dev] Serious issue: fail-safe and hotplugging
sajol...@pimienta.org wrote (27 Feb 2014 11:11:11 GMT) : > I think I already did 50 % of the work. I think I'll push a proposal for > last comments before the freeze. \o/ > I'm glad I can be sloppy with freeze on documentation work... Just keep in mind the translators' needs :) Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Serious issue: fail-safe and hotplugging
intrigeri: > anonym wrote (21 Feb 2014 05:10:13 GMT) : >> All this is done, as per my other replies. > > \o/ > >> In summary, tickets #6552, #6540, #6550, #6111 and #6541 are now in your >> court. :) > > I'll review this once you have pushed your feature/spoof-mac branch to > the greeter repo. But the merge will still be blocked by the doc > improvements sajolida is working on. sajolida, any ETA? I think I already did 50 % of the work. I think I'll push a proposal for last comments before the freeze. I'm glad I can be sloppy with freeze on documentation work... signature.asc Description: OpenPGP digital signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Serious issue: fail-safe and hotplugging
21/02/14 12:20, intrigeri wrote: > anonym wrote (21 Feb 2014 05:10:13 GMT) : >> All this is done, as per my other replies. > > \o/ > >> In summary, tickets #6552, #6540, #6550, #6111 and #6541 are now in your >> court. :) > > I'll review this once you have pushed your feature/spoof-mac branch to > the greeter repo. Sorry about that. Now pushed. Cheer! ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Serious issue: fail-safe and hotplugging
anonym wrote (21 Feb 2014 05:10:13 GMT) : > All this is done, as per my other replies. \o/ > In summary, tickets #6552, #6540, #6550, #6111 and #6541 are now in your > court. :) I'll review this once you have pushed your feature/spoof-mac branch to the greeter repo. But the merge will still be blocked by the doc improvements sajolida is working on. sajolida, any ETA? Cheers! -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Serious issue: fail-safe and hotplugging
06/01/14 16:58, intrigeri wrote: > sorry for the delay, and sorry in advance for the bad mood that > probably impacts this email, I'm a bit grumpy today. :) > anonym wrote (31 Dec 2013 00:45:51 GMT) : >> 30/12/13 13:48, intrigeri wrote: >>> anonym wrote (29 Dec 2013 21:21:35 GMT) : 27/12/13 18:05, intrigeri wrote: Approach 1 -- >>> A seemingly obvious fix would be to move the fail-safe from its current location, tails-unblock-network, into tails-spoof-mac, which is run by the MAC spoofing udev hook when network devices are added. The fail-safe would then act on a per-device basis, and it would be closer to the spoofing, which both are nice (bonus: the problem you raised about "macchanger can't retrieve the permanent MAC address" would be really easy to fix). >>> >>> I like this approach, and I hope we can make it work fine. Let's see. [...] Let's just drop all these sub-discussions. I'm in complete agreement with you now. Approach #1 it is! >> Hmm. I just think I came up with a fix that makes Approach #1 robust (it >> can be used for Approach #2 too, but it doesn't make as much sense): we >> use ferm/iptables to drop all outgoing traffic from interfaces that have >> not been explicitly said to be "ok" by the fail-safe code. [...] > I'm not convinced that this added code, design complexity, and thus > difficulty to audit is more likely to protect our users than the lack > of it. AIUI, the only bonus is for a corner case, which the potential > drawbacks are for everybody. Agreed. Looking back at all this I don't know what I was thinking. I'm honestly sorry for having forced you through all this crap. > But perhaps I just want to see this branch merged ASAP in some > acceptable state, and am starting to get tired of thinking about it. > The current state + a few documented known issues + the small fixes > I've asked for a while ago, would be already much better than what our > users have in hand right now. All this is done, as per my other replies. I've also implemented approach #1 and fixed #6552. See commits 7b7ba02d..e85b325. It's all pushed into feature/mac-spoof, both Tails and Greeter repos, and I've built a new Tails Greeter snapshot, uploaded it, and merged the feature branch + APT suite into experimental. In summary, tickets #6552, #6540, #6550, #6111 and #6541 are now in your court. :) Cheers! ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Serious issue: fail-safe and hotplugging
Hi, sorry for the delay, and sorry in advance for the bad mood that probably impacts this email, I'm a bit grumpy today. anonym wrote (31 Dec 2013 00:45:51 GMT) : > 30/12/13 13:48, intrigeri wrote: >> anonym wrote (29 Dec 2013 21:21:35 GMT) : >>> 27/12/13 18:05, intrigeri wrote: >>> Approach 1 >>> -- >> >>> A seemingly obvious fix would be to move the fail-safe from its current >>> location, tails-unblock-network, into tails-spoof-mac, which is run by >>> the MAC spoofing udev hook when network devices are added. The fail-safe >>> would then act on a per-device basis, and it would be closer to the >>> spoofing, which both are nice (bonus: the problem you raised about >>> "macchanger can't retrieve the permanent MAC address" would be really >>> easy to fix). >> >> I like this approach, and I hope we can make it work fine. Let's see. >> >>> However, a big issue with this approach is that if NetworkManager is >>> running when tails-spoof-mac is run by the udev hook (which will be the >>> case every time a device is hotplugged after TG login) then there's a >>> race: will NM spawn network activity before the fail-safe is triggered >>> in case of a MAC spoofing error? This doesn't feel robust at all. >> >> Are you sure NM picks up newly added devices before udev has finished >> adding it to the system (which, I hope, is indicated by the fact that >> all udev rules have completed their job, which, I hope, includes >> running all hooks)? > I wasn't sure, but I've now verified that there indeed is *no* race with > NM. I verified by adding a sleep(1) hooked via an udev rule, and NM is > delayed for the duration of the sleep. Good. > It should be noted, though, that > the device is fully operational during the sleep; I could get the > network up via e.g. `dhclient eth0`. Hence, if "something else" can > cause network activity at that time, then there's a race between that > "something else" and the spoofing instead. I don't think we care about this case. One can shoot themselves in the foot by doing random things as root, no news. > It remains to investigate why NM waits for all udev hooks as we don't > want to depend on voodoo. Any ideas? I had a quick look at the (Wheezy) source, and it looks like the answer may be found with `git grep -i device_added -- src', in src/*udev*.c, and by looking for uevent and netlink handling. I suspect the kernel simply does not announce that the added device is available before all udev hooks have run, which makes very much sense to me, and does not feel like voodoo :) > Any way, slightly off-topic, but regarding "USB doesn't do DMA" I think > that's actually false. A quick search yielded: OK. >>> What to do? >>> === >> >>> If we cannot solve the problems in Approach 1 or 2 (and cannot come up >>> with a superior Approach 3) then I guess we will have to pick whatever >>> we consider the least bad of those two, and perhaps document that >>> hotplugging after TG login isn't safe w.r.t. MAC spoofing. >> >> Another approach (that only works for USB devices) worth looking at is >> the Linux USB authorization support: >> >> * Documentation/usb/authorization.txt >> * >> http://www.irongeek.com/i.php?page=security/plug-and-prey-malicious-usb-devices#3.2_Locking_down_Linux_using_UDEV >> >> So, my current position is: if approach #1 is doable in a non-racy way >> (i.e. if NM does not picks up a new device before udev is done with >> it), then let's KISS and just do it. Else, either go with approach #2, >> or with approach #1 (in a bit racy way), that both require documenting >> the limitations in rare, edge cases. > So for KISSing and picking Approach #1 it all boils down to whether we > consider NM as the only possible/reasonable participant in the > aforementioned race. I guess it is, but who knows? Given how complex a > modern Linux system is, it's kind of hard to exhaustively rule out > everything about anything. :) I think we are already implicitly delegating network management to NetworkManager, and we are not installing anything that does the same kind of things as NM. One thing that could change this is installing stuff that plays with the networking stack at low levels, such as virtualization host software, VPN software or similar, but we don't ship anything like that yet, and apart of that, really, I don't see. I would be entirely comfortable with making the asumption that NetworkManager is the sole piece of software responsible for this part of Tails, and the only participant to this race. I mean, it's about the same as our firewall configuration: we've not proven that nothing but ferm can potentially modify it. Still, we know this little OS called Tails well enough to be reasonably confident that we are not installing anything else (but NM, actually) that plays with iptables/netfilter. We are confident that we don't install anything that plays with the browser proxy configuration but Torbutton, FoxyProxy, and potentially a few environment
Re: [Tails-dev] Serious issue: fail-safe and hotplugging [Was: MAC spoofing: current status?]
30/12/13 13:48, intrigeri wrote: > anonym wrote (29 Dec 2013 21:21:35 GMT) : >> 27/12/13 18:05, intrigeri wrote: >> Approach 1 >> -- > >> A seemingly obvious fix would be to move the fail-safe from its current >> location, tails-unblock-network, into tails-spoof-mac, which is run by >> the MAC spoofing udev hook when network devices are added. The fail-safe >> would then act on a per-device basis, and it would be closer to the >> spoofing, which both are nice (bonus: the problem you raised about >> "macchanger can't retrieve the permanent MAC address" would be really >> easy to fix). > > I like this approach, and I hope we can make it work fine. Let's see. > >> However, a big issue with this approach is that if NetworkManager is >> running when tails-spoof-mac is run by the udev hook (which will be the >> case every time a device is hotplugged after TG login) then there's a >> race: will NM spawn network activity before the fail-safe is triggered >> in case of a MAC spoofing error? This doesn't feel robust at all. > > Are you sure NM picks up newly added devices before udev has finished > adding it to the system (which, I hope, is indicated by the fact that > all udev rules have completed their job, which, I hope, includes > running all hooks)? I wasn't sure, but I've now verified that there indeed is *no* race with NM. I verified by adding a sleep(1) hooked via an udev rule, and NM is delayed for the duration of the sleep. It should be noted, though, that the device is fully operational during the sleep; I could get the network up via e.g. `dhclient eth0`. Hence, if "something else" can cause network activity at that time, then there's a race between that "something else" and the spoofing instead. (In case you wonder why I didn't investigate the NM race possibility earlier it was because I first wanted to explore Approach 2 (which took quite some time) since that would eliminate this class of issues.) It remains to investigate why NM waits for all udev hooks as we don't want to depend on voodoo. Any ideas? > If NM waits for this to be done (and I would hope so), then this > approach is actually not racy at all, is it? Correct. Well, at least as long as we consider NetworkManager as the only possible (and automatic) cause of network activity. > If my guess is wrong, then this approach is definitely racy. We could > mitigate this a little bit by (first thing) disabling the just-added > interface in the script run by the udev hook, with something like: > > nmcli dev disconnect iface $IFACE > > Potential problems: > > * I see this is available in current sid's NM, no idea if that's the > case on Squeeze. > * I see no way to re-enable the device with nmcli, so it would > probably require reloading or SIGHUP'ing or (worst case) > restarting NM once we have spoofed the new NIC's MAC address. > > Another similar hack could be to add the newly plugged device to the > list of unmanaged ones, see "Unmanaged devices" on > https://wiki.gnome.org/Projects/NetworkManager/SystemSettings. > > Of course, this would still be a bit racy, but perhaps acceptable. > > Another hack could be to add to /etc/network/interfaces, at Greeter > time, a broken static configuration snippet for all possible names > that could be used for NICs plugged in the future. IIRC, NM fully > ignores devices that are listed in that file unless they're configured > to use DHCP (not sure what's the current state of the art in Wheezy > and later, but I expect README.Debian to document this). Then, when > a new NIC is plugged in and we have successfully spoofed its MAC > address, then we can remove the corresponding configuration snippet > and gently ask NM to manage it, with a NM reload or SIGHUP or — worst > case — restart. Ugly and not that easy to get right (listing the names > would be a pain, to start with), yeah, but probably more robust in the > end than the other ideas raised in approach #1. Still, I hope we can > avoid this. Right. I had also considered at least the "unmanaged devices in NM" solution, but I *really* think we should avoid adding such complex and possibly fragile hacks if possible. >> Approach 2 >> -- > >> An alternative fix that would keep the robustness of the current >> implementation (in fact, very little in the current implementation would >> change, at least compared to Approach 1) would be to disallow >> hotplugging of network devices after TG login. While this will add some >> user inconvenience, I think it's acceptable > > Fully agreed. > > More specifically though, this would bring one (minor) UX issue: > careful people have got used to 1. boot Tails; 2. login; 3. stop NM; > 4. plug their NIC; 5. spoof the MAC for their NIC; 6. start NM. So, > they would need to change their existing habits entirely, and plug the > NIC before booting. I think that can very well be addressed by a tiny > bit of documentation, which we'll need anyway if we go with > this approach. A
Re: [Tails-dev] Serious issue: fail-safe and hotplugging [Was: MAC spoofing: current status?]
Hi, anonym wrote (29 Dec 2013 21:21:35 GMT) : > 27/12/13 18:05, intrigeri wrote: [...] >> I'm afraid this won't work very well for drivers that macchanger can't >> retrieve the permanent MAC address from, e.g.: [...] > However, let's leave this issue a side for a moment, OK. Filed #6552 so that it doesn't slip through, then. > The problem > === > Since the MAC spoofing fail-safe is run only *once*, immediately after > logging in with Tails Greeter, there's no fail-safe for devices > hotplugged after logging in. > [...] > Approach 1 > -- > A seemingly obvious fix would be to move the fail-safe from its current > location, tails-unblock-network, into tails-spoof-mac, which is run by > the MAC spoofing udev hook when network devices are added. The fail-safe > would then act on a per-device basis, and it would be closer to the > spoofing, which both are nice (bonus: the problem you raised about > "macchanger can't retrieve the permanent MAC address" would be really > easy to fix). I like this approach, and I hope we can make it work fine. Let's see. > However, a big issue with this approach is that if NetworkManager is > running when tails-spoof-mac is run by the udev hook (which will be the > case every time a device is hotplugged after TG login) then there's a > race: will NM spawn network activity before the fail-safe is triggered > in case of a MAC spoofing error? This doesn't feel robust at all. Are you sure NM picks up newly added devices before udev has finished adding it to the system (which, I hope, is indicated by the fact that all udev rules have completed their job, which, I hope, includes running all hooks)? If NM waits for this to be done (and I would hope so), then this approach is actually not racy at all, is it? If my guess is wrong, then this approach is definitely racy. We could mitigate this a little bit by (first thing) disabling the just-added interface in the script run by the udev hook, with something like: nmcli dev disconnect iface $IFACE Potential problems: * I see this is available in current sid's NM, no idea if that's the case on Squeeze. * I see no way to re-enable the device with nmcli, so it would probably require reloading or SIGHUP'ing or (worst case) restarting NM once we have spoofed the new NIC's MAC address. Another similar hack could be to add the newly plugged device to the list of unmanaged ones, see "Unmanaged devices" on https://wiki.gnome.org/Projects/NetworkManager/SystemSettings. Of course, this would still be a bit racy, but perhaps acceptable. Another hack could be to add to /etc/network/interfaces, at Greeter time, a broken static configuration snippet for all possible names that could be used for NICs plugged in the future. IIRC, NM fully ignores devices that are listed in that file unless they're configured to use DHCP (not sure what's the current state of the art in Wheezy and later, but I expect README.Debian to document this). Then, when a new NIC is plugged in and we have successfully spoofed its MAC address, then we can remove the corresponding configuration snippet and gently ask NM to manage it, with a NM reload or SIGHUP or — worst case — restart. Ugly and not that easy to get right (listing the names would be a pain, to start with), yeah, but probably more robust in the end than the other ideas raised in approach #1. Still, I hope we can avoid this. > Approach 2 > -- > An alternative fix that would keep the robustness of the current > implementation (in fact, very little in the current implementation would > change, at least compared to Approach 1) would be to disallow > hotplugging of network devices after TG login. While this will add some > user inconvenience, I think it's acceptable Fully agreed. More specifically though, this would bring one (minor) UX issue: careful people have got used to 1. boot Tails; 2. login; 3. stop NM; 4. plug their NIC; 5. spoof the MAC for their NIC; 6. start NM. So, they would need to change their existing habits entirely, and plug the NIC before booting. I think that can very well be addressed by a tiny bit of documentation, which we'll need anyway if we go with this approach. > (also, it's pretty close to > some of the proposed solutions for bug #5451: protect against external > bus memory forensics). First, I expect that most such hotplugged NICs are either USB, or plugged into a bus we want to disable post-login as part of #5451. The latter doesn't matter much IMO yet (since it'll be disabled at a lower level at some point, and until we complete #5451, there's little point in protecting against this at the NIC level only). For USB NICs, that's a different matter. On the one hand, we have not considered disabling USB devices hotplug as part of #5451, mostly because 1. USB doesn't do DMA (right?) and 2. many usecases we want to support, e.g. Tails Installer, depend on the ability to do so. So, I doubt we'll ever want to disable USB hotplug entirely pos
[Tails-dev] Serious issue: fail-safe and hotplugging [Was: MAC spoofing: current status?]
27/12/13 18:05, intrigeri wrote:
> anonym wrote (22 Dec 2013 15:08:56 GMT) :
>> 29/11/13 12:31, intrigeri wrote:
>> +get_permanent_mac_of_nic() {
>> +macchanger ${1} | sed -n
>> "s/^Permanent\s*MAC:\s*\([0-9a-f:]\+\)\s.*$/\1/p"
>> +}
>> [...]
>> +nic_has_spoofed_mac() {
>> +[ "$(get_permanent_mac_of_nic ${1})" != "$(get_current_mac_of_nic
>> ${1})" ]
>> +}
>
> I'm afraid this won't work very well for drivers that macchanger can't
> retrieve the permanent MAC address from, e.g.:
>
> $ sudo macchanger eth0
> ERROR: Can't read permanent MAC: No such device
> Permanent MAC: 00:00:00:00:00:00 (Xerox Corporation)
> Current MAC: f0:de:f1:11:11:11 (Wistron Infocomm (kunshan)co)
Thanks for pointing this out. I didn't know this was true for some devices.
> I'm unsure what special casing can be done about it, but it would be
> great to avoid *always* concluding such a NIC has a spoofed MAC.
>
> Maybe we should simply save the original MAC before attempting to
> spoof it, and compare later?
Right. To clarify, we'd need to save the MAC address to somewhere in the
filesystem in `tails-spoof-mac` (called by the MAC spoof udev hook)
since we also need the functionality of `nic_has_spoofed_mac()` in the
fails-safe in `tails-unblock-network`.
However, let's leave this issue a side for a moment, because I just
realised that there's a severe issue with having the fail-safe in
tails-unblock-network (at least in the current state of things).
The problem
===
Since the MAC spoofing fail-safe is run only *once*, immediately after
logging in with Tails Greeter, there's no fail-safe for devices
hotplugged after logging in.
Solution
At the moment I only have bad or partial solutions:
Approach 1
--
A seemingly obvious fix would be to move the fail-safe from its current
location, tails-unblock-network, into tails-spoof-mac, which is run by
the MAC spoofing udev hook when network devices are added. The fail-safe
would then act on a per-device basis, and it would be closer to the
spoofing, which both are nice (bonus: the problem you raised about
"macchanger can't retrieve the permanent MAC address" would be really
easy to fix).
However, a big issue with this approach is that if NetworkManager is
running when tails-spoof-mac is run by the udev hook (which will be the
case every time a device is hotplugged after TG login) then there's a
race: will NM spawn network activity before the fail-safe is triggered
in case of a MAC spoofing error? This doesn't feel robust at all.
Approach 2
--
An alternative fix that would keep the robustness of the current
implementation (in fact, very little in the current implementation would
change, at least compared to Approach 1) would be to disallow
hotplugging of network devices after TG login. While this will add some
user inconvenience, I think it's acceptable (also, it's pretty close to
some of the proposed solutions for bug #5451: protect against external
bus memory forensics).
The problem with this approach is how to disallow hotplugging. Simply
restoring the blacklist isn't very robust; since the blacklist works on
the module loading (modprobe) level, devices that happen to use the same
module as a device that was added before TG login can then be
successfully hotplugged even after TG login.
For robustness we'd have to move from the blacklist to something
lower-level. I've looked into what's possible to do with udev rules.
What I'd like is to write a rule which would make udev completely ignore
network devices, so they would remain disabled. That rule would be
*temporarily* removed in tails-unblock-network so all network devices
present at that particular time will be probed and activated. However, I
can't find a way to do this in current udev as all ways to do this seem
to have been deprecated, like the following:
SUBSYSTEM=="net",
ACTION=="add",
ATTR{type}=="1",
OPTIONS+="ignore_device"
The "ignore_device" OPTION was deprecated in udev 148 (and perhaps it
didn't do what I wanted any way). Does any one know of an alternative to
"ignore_device"?
What to do?
===
If we cannot solve the problems in Approach 1 or 2 (and cannot come up
with a superior Approach 3) then I guess we will have to pick whatever
we consider the least bad of those two, and perhaps document that
hotplugging after TG login isn't safe w.r.t. MAC spoofing.
I'm all ears for any input! Meanwhile I'll continue looking for
solutions and alternative approaches.
Cheers!
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
