Re: [Tails-dev] MAC spoofing: current status?
anonym wrote (29 Dec 2013 00:32:33 GMT) : If you want, I'll cherry-pick the relevant commits into master later today or tomorrow. Shall I? Please do! Done. 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
Re: [Tails-dev] Please review'n'merge bugfix/6478
Hi, intrigeri wrote (16 Dec 2013 12:46:38 GMT) : intrigeri wrote (12 Dec 2013 12:00:42 GMT) : WinterFairy, please review my bugfix/6478 branch, that builds on top of yours. Untested yet. I'll ask a formal go ahead for merging once I, or someone else, has tested it for many languages. WinterFairy, will you take care of the testing and review, or should I reassign the ticket to someone else? I have successfully tested bugfix/6478 (with gedit and nautilus) for English, French, Chinese, Korean and Japanese. Reassigning to bertagaz for review. 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
Re: [Tails-dev] MAC spoofing: current status?
intrigeri wrote (27 Dec 2013 17:05:48 GMT) : I'm now going to test this branch a bit. I'll report back. Works fine for me on a ThinkPenguin Royal, a MacBook Pro 13-inch Mid 2012, and inside a libvirt/qemu VM. Congrats! 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
Re: [Tails-dev] Release schedule for Tails 0.22.1
On Sun, Dec 29, 2013 at 04:27:03PM +0100, intrigeri wrote: Hi, here's an update on the 0.22.1 release process. See the bottom part, that expects answers from core developers. intrigeri wrote (08 Dec 2013 17:19:51 GMT) : I'm prepared to make exceptions to our usual stable merge rules for some edge cases: * upgrading Linux to 3.12, to fix security issues in 3.10; this is blocked by #6460 (memory wipe broken with 3.11+); this is high priority IMHO. Any taker? I've made some progress (more failed attempts to fix it), and the ticket has more ideas to be tried. It would be really great if someone took it over from here. I understand that, but can't promise much myself on it at the moment. My plate is already quite filled, but if I find some spare time, I'll have a look, even if I feel like it's a quite over my capacities. * enabling incremental upgrades by default, if testing is successful enough, and if fixing most important problems is possible with minor changes Looks like this will happen: I expect we can merge feature/incremental-upgrades-integration very early in January :) Yay! Core developers: ASAP, please volunteer for the test days, or make it clear that you can't make it, so we can reschedule slightly if needed. Ping? I'm good and should be available for the planned test days. Also, the freeze is coming soon, quite a few bugfix branches are pending for review'n'merge, and there are more to come soon (Torbutton and Iceweasel prefs updates). bertagaz said he would take care of these ones today: * #6496 (Drop sqlite3, nss and nspr backports from our APT repository) * #6477 (getTorbuttonUserAgent differs from browser user-agent) I'll finish these tonight, already spend my afternoon testing your test/rjb-migration branch enhancement. ... but those other ones need a reviewer: * #6478 (Keyboard shortcuts use QWERTY mapping instead of AZERTY on French keyboard) * #6536 (Windows camouflage script does not set the browser icon to IE's one anymore) If there is no takers, I should be available to review them before the merge, but I have to admit I'd be glad not to do so: I feel like spending my time reviewing those times :) bert. ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Please review'n'merge test/rjb-migration
On Fri, Dec 27, 2013 at 07:36:15PM +0100, intrigeri wrote: berta...@ptitcanardnoir.org wrote (27 Dec 2013 09:36:32 GMT) : Just one word to sum up my feelings: hurray! :) :) The test suite is now entirely green for me, with the two known exceptions that are documented (git grep XXX -- features). Please review my changes and merge it into devel if it looks good! Tickets that will go away: #6314, #6399. Done, merged into devel, haven't seen the test suite in such a good shape since a long time, congrats! The parent ticket (#5731) is still blocked by #6400, as nobody commited to either upstream our stuff into the ruby-sikuli Gem, or to maintain our own adapter on the long term. I'm unsure what conclusion we should draw of it. Admitedly, the new setup is way less scary than the previous one, and our adapter is 85 lines long, but still, I'm concerned we might happily be replacing it with another kind of technical debt. Shall we just forget about it and close #6400 as rejected? Thoughts? I've had a quick look at a way to implement that upstream. Using the RUBY_ENGINE variable, it seems easy to have the gem selecting the right handler depending on which interpreter is used. Still there are some subtilities in our code that I'm not sure to understand, this is quite low level, and I'm not sure to be able to handle this upstreaming myself alone. In particular, I'd like to hear what anonym thinks of it. Me too. :) bert. ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Release schedule for Tails 0.22.1
Hi, On Sun, 29 Dec 2013 16:27:03 +0100 intrigeri intrig...@boum.org wrote: here's an update on the 0.22.1 release process. See the bottom part, that expects answers from core developers. intrigeri wrote (08 Dec 2013 17:19:51 GMT) : Core developers: ASAP, please volunteer for the test days, or make it clear that you can't make it, so we can reschedule slightly if needed. Ping? I scheduled a test day on the 20th, but seems like I forgot to communicate about it. Also, the freeze is coming soon, quite a few bugfix branches are pending for review'n'merge, and there are more to come soon (Torbutton and Iceweasel prefs updates). bertagaz said he would take care of these ones today: * #6496 (Drop sqlite3, nss and nspr backports from our APT repository) * #6477 (getTorbuttonUserAgent differs from browser user-agent) ... but those other ones need a reviewer: * #6478 (Keyboard shortcuts use QWERTY mapping instead of AZERTY on French keyboard) * #6536 (Windows camouflage script does not set the browser icon to IE's one anymore) Any taker? I could do it the week of the freeze, but won't mind if it is done before. Cheers ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
[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
Re: [Tails-dev] Please review'n'merge feature/torbrowser-24.2.0esr-1+tails1
On Mon, Dec 16, 2013 at 01:42:34PM +0100, intrigeri wrote: Hi, this is a follow-up, with a better fix, to the quick fix introduced by bugfix/use-our-own-sqlite. The details are on the ticket: https://labs.riseup.net/code/issues/6496 When merging this branch, please drop the packages listed on the ticket from our APT repo. Then, we can 1. drop the corresponding temporary APT pinning rules since they won't be needed anymore; 2. take care of #6497 (I'm on it). Assigned to bertagaz for review, candidate for 0.22.1. Done, branch merged in devel (git and APT repo), packages removed from the APT repo, in the devel suite. bert. ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Please review'n'merge feature/torbrowser-24.2.0esr-1+tails1
Hi, berta...@ptitcanardnoir.org wrote (29 Dec 2013 23:34:43 GMT) : Assigned to bertagaz for review, candidate for 0.22.1. Done, branch merged in devel (git and APT repo), packages removed from the APT repo, in the devel suite. Great! That's a candidate for 0.22.1, so please merge into stable too (and do the APT thing too). If you prefer, I can do it. 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
Re: [Tails-dev] Please review'n'merge bugfix/6536-IE-icon-in-Windows-camouflage-mode
berta...@ptitcanardnoir.org wrote (29 Dec 2013 23:37:53 GMT) : Candidate for 0.22.1 = please merge into stable and devel. While testing other branches, I tested this one too, so I merged it too. Cool! It seems you forgot to merge into stable. Nice catch! Our automated test suite catched it! :) No idea why this was not detected when it was run for 0.22, but oh well, I guess some earlier step was broken, and we did not do the rest of the tests manually for some reason. 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
Re: [Tails-dev] Please review'n'merge bugfix/6536-IE-icon-in-Windows-camouflage-mode
On Mon, Dec 30, 2013 at 12:55:39AM +0100, intrigeri wrote: berta...@ptitcanardnoir.org wrote (29 Dec 2013 23:37:53 GMT) : Candidate for 0.22.1 = please merge into stable and devel. While testing other branches, I tested this one too, so I merged it too. Cool! It seems you forgot to merge into stable. Oh right, will do so. Nice catch! Our automated test suite catched it! :) No idea why this was not detected when it was run for 0.22, but oh well, I guess some earlier step was broken, and we did not do the rest of the tests manually for some reason. Yeah, I think I did the tests manually in the end, but didn't notice that the icon wasn't the right one. bert. ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Please review'n'merge feature/torbrowser-24.2.0esr-1+tails1
On Mon, Dec 30, 2013 at 12:53:30AM +0100, intrigeri wrote: Hi, berta...@ptitcanardnoir.org wrote (29 Dec 2013 23:34:43 GMT) : Assigned to bertagaz for review, candidate for 0.22.1. Done, branch merged in devel (git and APT repo), packages removed from the APT repo, in the devel suite. Great! That's a candidate for 0.22.1, so please merge into stable too (and do the APT thing too). If you prefer, I can do it. Done. ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
