Autor: anonym Data: A: The Tails public development discussion list Assumpte: Re: [Tails-dev] disabling MAC spoofing by default in VM's [Was:
[RFC] Design (and prototype) for MAC spoofing in Tails]
21/11/13 09:17, intrigeri wrote: > Hi,
>
> (Splitting into per-topic sub-threads to make the discussion easier
> to follow.)
>
> anonym wrote (21 Nov 2013 05:58:37 GMT) :
>> As pointed out in a different part of this thread, some virtual machines
>> don't like MAC spoofing at all (e.g. in VirtualBox networking breaks
>> completely for NAT- and bridge-based adapters). Therefore I also made
>> T-G check if we're running in a virtual machine, and if so it changes
>> the default to *disable* MAC spoofing. For more info, see the blueprint,
>> section "MAC spoofing and virtual machine networking issues".
>> Furthermore, if the user checks the MAC spoofing box, a warning is
>> shown. The warning disappears if the box is unchecked, which is unlike
>> the warning shown when the admin passwords mismatch, which never removes
>> the warning. For greater consistency, I also made the latter warning
>> disappear once once changes any of the password entries, which I think
>> is a general improvement.
>
> I'm concerned about the impact on our test suite: it seems suboptimal
> to (automatically) test code paths that are different from the ones
> most users will go through.
Even if we add a comprehensive cucumber feature that tests all scenarios
we think matter for both cases (i.e. enabled and disabled)?
> IIRC we're setting a kernel cmdline
> parameter when running the test suite, so perhaps this changing of
> defaults could be disabled when a testing environment is detected?
This would be both easy and appropriate, yes.
Another approach is to change the default only for known problematic VMs
(currently only VirtualBox), which is made easy since virt-what tells us
which VM it detects. We this we would *by default* spoof the MAC address
of Tails in the scenario where someone runs Tails in a e.g.
libvirt/qeumu with a bridged adapter on a hostile network (it's up to
the user to then also spoof the much more important *real* MAC address
of the host computer). A small gain, I suppose.
BTW, the current behavior of hiding the warning isn't optimal. It'd be
better to always show the warning (even without my above suggest) since
we're overriding a default, and the that should be made clear
immediately to any user looking at the "more options" page.
> (Assuming the libvirt/qemu stack we're using is not affected by the
> same issues as VirtualBox.)
It's not. libvirt/qemu works just fine with MAC spoofing.
